Moving from Bower to NPM

The “definitely not the” node package manager (npm) has recently moved up a major version to v3.0 and in the process has signalled its intent to start handling client-side packages. It supports any old git repository so the benefit of bower is basically gone now. It’s time to stop using two package managers and standardize on one.

There are three things I need to do. Firstly, I need to figure out how to get packages that aren’t in the npm package repository yet. Secondly, I need to handle my standard gulp recipe for building the library area. Finally, since I need to do extra stuff to the polymer package before using it, I need to adjust the build process for Polymer.

1. Handling Non-Repository Packages

npm has a bunch of ways you can handle non-repository packages. You could run your own repository – which is probably overkill for most projects. You can also install a .tgz or .zip file either locally or from a URI. You can also install from GitHub.

A quick warning – the first time you install from github, it will ask you for verification. On Windows, this was painful. Answering the questions and continuing then returning and re-running the command worked for me.

Polymer is not in the npm registry. There is a package called polymer – but it’s something different. There are also lots of things dealing with Polymer, but not polymer itself. Let’s install Polymer with this command:

npm install --save github:Polymer/polymer

As of this writing, it will install v1.0.5 of Polymer – exactly the latest version. In the package.json, it looks a little different. Here is the top of my package.json file:

  "version": "1.0.0",
  "name": "AspNetPolymer",
  "private": true,
  "dependencies": {
    "Polymer": "polymer/polymer",
    "font-awesome": "^4.3.0",
    "webcomponents.js": "^0.7.2"

Note that I’ve moved the packages from bower.json to the package.json in the dependencies section. In the process, I had to rename the webcomponentsjs to webcomponents.js – you may encounter other naming differences. You can edit the package.json in Visual Studio and it will run a restore packages process when complete. Polymer is a little bit different though – it specifies the library name (Polymer) and the path on You can use private git repositories as well if you like (an alternative to NPM Enterprise, perhaps?).

2. Building the Libraries

Now that I’ve got the libraries on my machine in my source area, I want to move them into the right place on wwwroot. I use gulp for my build process, so here is the recipe:

gulp.task("libraries", function () {
    return gulp.src(plugins.npmFiles(), { base: "./node_modules" })
        .pipe(gulp.dest(config.dest + "/lib"));

The plugins.npmFiles() call is provided by gulp-npm-files – a module for this exact purpose. I’m using gulp-load-plugins to create the plugins object that loads this plugin.

3. Post-processing the libraries

Back to Polymer. Polymer is distributed as three files – polymer.html, polymer-mini.html and polymer-micro.html. I want to vulcanize these into one file. I use this to create a elements/polymer area:

 * Build the vulcanized Polymer library that we need
gulp.task("polymer", ["libraries"], function () {
    var polymerPath = "./node_modules/Polymer/polymer.html";

    return gulp.src(polymerPath)
        .pipe(gulp.dest(config.dest + "/elements/polymer"));

The only real thing I had to do here was change the path to the Polymer library – it’s in node_modules instead of bower_components. I could build this into the libraries pipeline using gulp-filter (and look for **/polymer.html). The reduction in one task doesn’t seem worth it. Most libraries are distributed already built.

That’s pretty much all there was to it. If I’m developing using Aurelia, I will still use two package managers (jspm and npm), but most things can be developed with just one package manager now. The support for npm in Visual Studio is just a bonus to me.