Gone are the days when concatenating and uglifying your source code was sufficient. With es6 and es7 developing more rapidly than browser vendors can keep up with, typescript and flow type checking, and other aberrant requirements your project may have, the desire to use something to magically pipe and bundle in one fell swoop can be quite attractive. This leads us to build tools like webpack, grunt, and gulp. With a surgeon’s hand and an abundance of third-party modules you can carefully construct something that will spit out all of your assets with something like: gulp build.
Awesome. Right? At least for a few weeks until one of the dependencies deprecates|breaks and you need to upgrade and as soon as you know it’s 1 in the morning and you’ve been presented with infographics like this all night:
So let’s unpack that (pun intended). These node automators are a third layer of abstraction on top of the actual utilities which do the heavy lifting. The strength of the glue which holds these two layers together is at the mercy of a developer or developers who may or may not be doing their best to pay attention to the developers who maintain the utilities in which they interface. The glue will break after a while unless you’ve got your eye on all of these layers. Even when vigilant, you probably won’t have a good time.
There are an increasing number of people frustrated with the vibrant JavaScript/node community because of the amount of new toolings being created every day. I believe the real frustration starts with how these tools are integrated.
So how can we make this better? I’d like to propose a stronger and more standalone approach:
- Don’t pollute your actual project’s package.json with build related modules. Any of them — browserify, babel, sass, ect. Even if you’re good about keeping them in
devDependencies. Keep your project in a clean state in a src/ folder. At the root, keep another package.json file which holds any build or development related modules. What needs to be compiled today, may run native (or change) tomorrow so it’s best to decouple that dependency.
- /package.json <- only dev deps
- /src/package.json <- only application deps
- /src/* <- the rest of the project- A wheel for automation has been around for a long time. Make use of bash, shell, and Makefiles. If you haven’t read it already, isaacs (creator of npm) wrote a great intro to Makefiles. This will allow you to interface with the utilities directly, not through something like webpack, gulp, or grunt. Upsides: 1) You will always use 100% of the options available to you without relying on the maintainers to update the master branch because you’re using the actual program — not an interface to it. 2) This also avoids that third layer of abstraction — the weak glue.
Lastly, I’ll leave you with some inspiration for actually executing on this in the form of a git repository, here.
So how about we not try to automate all the things with one thing?
