Deprecating gulp-util

Gulp 4 is finally happening 🎉 and gulp-util has been deprecated 😳. There are a lot of packages using it.

The Problem with gulp-util explains the move and provides this very helpful “rosetta stone” for guiding migrations:

 

• gutil.File => https://www.npmjs.com/package/vinyl
• gutil.replaceExtension => The .extname property on Vinyl objects or https://www.npmjs.com/package/replace-ext
• gutil.colors => https://www.npmjs.com/package/ansi-colors
• gutil.date => https://www.npmjs.com/package/date-format
• gutil.log => https://www.npmjs.com/package/fancy-log
• gutil.template => https://www.npmjs.com/package/lodash.template
• gutil.env => https://www.npmjs.com/package/minimist
• gutil.beep => https://www.npmjs.com/package/beeper
• gutil.noop => https://www.npmjs.com/package/through2
• gutil.isStream => Use the .isStream() method on Vinyl objects
• gutil.isBuffer => Use the .isBuffer() method on Vinyl objects
• gutil.isNull => Use the .isNull() method on Vinyl objects
• gutil.linefeed => Use the string '\n' in your code
• gutil.combine => https://www.npmjs.com/package/multipipe
• gutil.buffer => https://www.npmjs.com/package/list-stream
• gutil.PluginError => https://www.npmjs.com/package/plugin-error

 

Thankfully I’ve only been using it for logging and coloring terminal output — easy fixes.

I’ll be sticking with Chalk over ansi-colors for now. While saving a character (ansi vs chalk) is appealing, I’m not interested in supporting old version of node.js, so the reasoning behind gulp-cli#125 doesn’t apply.

No we haven’t forgotten how to program

I skimmed this HN discussion attached to David Haney’s NPM & left-pad: Have We Forgotten How To Program? post, but it appeared to quickly devolve. The original article is well written but misses one of the key ideas of NPM.

Tiny NPM modules are not useless.

Anyone who’s ever written more than three programs has almost certainly refactored something out into a shared library. Even if it’s just copy and paste, code was reused. DRY (Don’t Repeat Yourself) is not just a mantra, it’s common sense. 

The huge innovation NPM enables, and the fuel of JavaScript’s insane innovation engine, is that people started publishing all those tiny libraries and functions as shareable modules. Suddenly one person’s back-pocket toolkit is used and vetted by tens of thousands of eyes. Ideal solutions quickly bubble up. Bugs are isolated and edge cases are corrected. 

NPM is a social network.

Those five “eyes closed” minutes Haney says could have been spent writing our own functions instead gets focused on more interesting parts of the project. 

While admittedly immature at times, the JavaScript ecosystem is insanely altruistic and open. Batteries may not be included, but if you’re in need, hundreds of people are more than happy to give you theirs. 

This whole, latest, node/NPM drama scares me, but the saying “never bet against JavaScript” is true. As soon as it broke, people started fixing it. The term “patch” is completely appropriate here. After a day or two, I expect everything will be working smoothly again. 

Contributing to node modules

Writing this down since it always takes me a while to piece together after I’ve forgotten it. Basically local development of npm modules is all npm link

1. Clone the module somewhere locally
2. cd into the module directory
3. run npm link
4. cd into some project using the module
5. run npm link module-name

To clean this up afterwards, run npm unlink.

If you’re working on a dependency of a dependency, directly install the public version of that module before linking (I think?). Newer versions of NPM use a flat dependency graph and it should all just work. (couldn’t find a reference on this, sorry)

Template Engines

Nunjucks (JavaScript/node.js) is “essentially a port” of Jinja2 (Python) and Twig (PHP, backstory).

So basically everyone owes Armin Ronacher a huge thank you.