JS ecosystem is famous for it’s wide range of packages and tools. Besides the default package manager, which comes with Node.js – NPM (node package manager), there are Bower.js, Jam.js and many more.
For a quite long period, my default setup was like – NPM for all server-side components and Bower.js for client-side stuff. It worked quite good together, especially in conjunction with Require.js.
But recently, I switched to NPM only setup. That allowed me to use CommonJS style both front and back ends and got rid of task runners as Grunt and Gulp.
Doing a lot of back-end coding I really get used to
CommonJS style, which is simple, practical and powerful. CommonJS modularization is plain as,
1 2 3 4 5
Node.js highly popularized Common.js approach. And NPM appeared to be one of the best package managers ever developed.
But for front-end, NPM was not that suitable. First of all, because of browsers do not understand Common.js style of modules. Second,
npm modules are being placed to
./node_modules folder, with is typically the root of project, that made things complicated to refer those scripts from
index.html and configure server to server static resources from
Browserify came to change this.
npmpackages directly in a browser.
A lot of pure front-end frameworks and libraries were published to
npm. In fact, it’s more and more used for front-end libraries as according to NPM developers.
Of cause, nothing comes for free. The cost of Browserify is a build step. You have to introduce to transform Common.js application into a bundle which is loaded and executed by a browser.
Moreover, some packages are still being hosted on Bower. Even, it’s possible to use Bower packages together with NPM packages (by means of debowerify transformation) I quickly realized, that this approach is very unpractical.
So, during the last few months my main contributions on GitHub was adopting of some front-end packages, to be conformant to Common.js and publishing them on NPM after.
The NPM now is the only one package manager to use, both for front-end and backend.
All dependencies are mentioned on one file
package.json instead of several files.. and you will never forget to run
bower install, since
npm install will do install everything.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
The server side code,
1 2 3 4 5 6 7
The client side code,
1 2 3 4 5 6 7
The same style, feels nice and clean.
NPM is not only package manager. It’s also very simple task runner (or scripts runner). There is a special section, called
scripts responsible for that. Originally it’s been used to run some package related tasks (run tests, perform pre/post install configurations).
Traditionally Grunt.js and Gulp.js are ones that used dealing with compiling static assests. But CLI interface of many tools and stream piping could replace them.
As example, I’ll show pretty typical setup:
browserifyand apply minification
node-sassand apply minification
browserify need to be installed globally,
scripts section, will add such script,
Since I also use several transformations in my applications, the Browserify have to properly configured for that. It check’s if
browserify section, and if it does – will use it contents as own options.
1 2 3 4 5 6
As with Browserify,
node-sass need to be installed globally,
1 2 3
Now, let’s minify both assets using one of the best concepts ever – Unix pipes.
We need two packages additionally,
And corresponding scripts,
1 2 3 4 5 6
Now, let’s apply watching. One of the watchers I use for several years already, that works best for me is
nodemon is not only able to watch file changes and restart node processes if necessary, but also running custom commands.
1 2 3 4 5 6 7 8
Typically, you need to run few tasks simultaneously, e.g. build all scripts or watch all application. We can combine commands, by running background tasks,
To build full app,
or to watch it,
Global packages are not cool, cause they might be missing on developers box there application is cloned. Moreover, dependency management becomes a bit more complex, if you need to work on different projects depending on different tools versions. As @bcomnes very correctly noticed, all tools as
uglify etc. can be installed as local
dev-dependency, which are fetched during
npm install and will be available to call inside project folder as global commands,
package.json got such update,
1 2 3 4 5 6
As example, please refer to brick, the project I currently use as boilerplate for new applications.