npm powers modern front-end development more than any other tool: It provides all modules you need to set up your Node.js based environment. If you use a build system like Gulp or Grunt you are very likely to install the modules you need via npm.
It all starts with specifying a
package.json file and defining the direct
dependencies your project has. With running
$ npm install the package
management system downloads these dependencies for you and installs them in the
way you need them.
But npm can do more than just installing dependencies. The one thing that I want to talk about are scripts.
Scripts are basically definitions of command line scripts that can be executed using npm and can completely replace your customized Gulp or Grunt workflow.
[…] scripts can be executed by running
npm run-script <pkg> <stage>.
~ From the documentation.
This post covers how to replace any other build system with npm and examples of tools I used while rewriting the siteeffect front-end.
Typically you would ask yourself why you should consider using npm instead of any other build system. For me it was to try it out and to learn more about the tools I use. I consider myself knowledgeable with Grunt and know my way around Gulp.
Apart from that using npm as your build tool removes complexity from your code since you don’t need to know any specific APIs of another tool. Furthermore you can remove at least one dependency from the list of tools developers and CIs need to install and work with. And thus you don’t need layer of abstraction for those tools (e.g. a lot of grunt-modules just add a wrapper on top of an existing CLI to run with grunt).
There are some steps I typically need with my build and development workflow:
- ES6 transpiler
- Dependency Management
- JS Uglification
- CSS pre- or postprocessor
- File watcher
All of these solutions can be set up with existing command line tools pretty easy.
For code style-checks you might want to use
JSCS. You need to add a configuration file
.jscsrc for JSCS to work.
Now let’s add a script for these tools in a
package.json file and install all
ES6 Transpiler & Dependency Management
With the aforementioned siteeffect.io project we use React.js with ES6 components. Thus we need some kind of ES6 to ES5 transpiler. If you don’t need such a step, just skip this section.
We use Babel.js for this job since it supports React’s JSX out of the box, has a lot of good ES6 features via polyfills (through core.js) and a strong community.
ES6 introduces a feature which should replace AMD and CommonJS with a better dependency management system: Modules. Babel supports the module syntax and transforms it to AMD or CommonJS (default).
Let’s combine it with what we already did.
For the sake of completeness I want to point out that you can use UglifyJS for JS minification and uglification.
For instance you can run
uglifyjs --compress --mangle -o dist/index.min.js -- dist/index.js
to minify the file we generated with Babel.
CSS Pre- or Postprocessor
Most developers still use a preprocessor for their CSS as for example Sass or
Some people (as for example me) want to use vanilla CSS with the enhancements of
ES6, the future) as for example Custom Properties, the
color() function and
There are tools to compile your CSS via both pre- and post-processors on their own. But there is also Pleeease which does both at once and has some more advantages as for example autoprefixer, rem-fallback (if you need to support IE8) and more.
Using Pleeease with it’s CLI is pretty straightforward:
Apart from that you need a configuration file called
following configuration supports the last 2 browser versions (eg. IE11 and
IE10). Thus there is no need for certain fallbacks.
Furthermore this configuration is made for a LESS project.
If you ever developed with Gulp, Broccoli or a similar build tool you sure used some kind of watch and/or serve task to re-compile files upon changing them.
onchange 'app/**/*.js' -- npm run babel
The part after
-- is the task you want to run if something changes.
You can even run some task before starting the watcher as for example in this
npm run babel && onchange 'app/**/*.js' -- npm run babel
Another tool which I want to try with my next project is watchman by Facebook which looks promising.
One more thing is important here: Running this one watch task needs one shell. If you want to run multiple watches you don’t want to use multiple shells which is why I integrated parallelshell.
parallelshell 'npm run watch:js' 'npm run watch:css'
This runs a JS and a CSS watcher in parallel.
Let's have a look at the current
Now we can compile some of these tasks together to create some development and build tasks.
Your Own Tasks
Usually you need some tasks for your build process which you write by yourself.
It’s easy to do this with npm: You can just run a script pointing to your own
file which holds any commands. For example:
script.js file can do whatever you want it to using Node.js’ features
Usually we want to run some of these tasks while developing but not as a watch, for instance tests. But there are more tasks which we need to run before a new release – you would call this a build. And lastly a CI tool might want to run some tests only without deploying your artifacts (Open Source projects using TravisCI or something similar).
Using npm this isn’t a problem at all. We can even utilize
Here are three example tasks: for dev, build and a CI
(you can scroll horizontally).
"dev": "parallelshell 'npm run css' 'npm run linter && npm run jscs && npm run babel && npm run test'",
"build": "parallelshell 'npm run css' 'npm run linter && npm run jscs && npm run babel && npm run uglify && npm run test-build'",
"ci": "npm run linter && npm run jscs && npm run coverage"
You can also add different configuration for dev and build as you can see with
Here is our final
Please remember to use configuration files for JSCS, JSHint and Pleeease.
"parallelshell \"npm run watch:js\" \"npm run watch:css\""
Basically just use
" instead of
Apart from all the good a workflow with npm brings it also has some disadvantages:
- You have to learn how to use CLIs of tools. With Grunt or Gulp you only have to know how to configure an abstraction and it’s always the same within a given system. CLIs tend to have inconsistencies.
- All your scripts are located within your
package.json. You can split them into separate scripts though.
- No abstraction layer. Grunt and also Gulp provide you with a layer of abstraction and utility functions for the tasks you write. Using npm you don’t get this.
- More work to standard tasks. Using a watch task and making it run in parallel with Grunt is really easy. Using npm you have to configure at least two CLIs to get the same result. Apart from that it’s not as easy to understand as other systems.
- More support in standard tasks. Some CLIs don’t provide every needed aspect out of the box. Tasks for Grunt and Gulp can add more functionality.
While combining different tools to configure build environment and workflow I learned a couple of new things and discovered new mechanisms to get the most out of a tool. "Old fashioned" build tools and task runners have a great community and other advantages. Npm on the other hand removes complexity and isn’t really hard to understand.
For me it’s clear: I don’t need Grunt or any other build tools. Npm is available anyway, so why not use it!