For instance, I’ve just pushed my parsing library, canto34, up to this location on npm, and the process was remarkably easy. The steps are –
1. create a user on the npm website.
2. Link your computer to it with npm command line;
3. Create a single file (package.json) which describes the package, its dependencies, and its location in git
4. Publish the package using npm again;
And that’s it — package deployed.
Now, that’s pretty sweet — anyone in the world can install the package using this command line;
npm install canto34
And get going with the library. But what about me? I want to continue to develop canto34 here on my dev machine, and use it in another project (in my case, a little program called Mettle that’s beginning to take shape.)
So I want to make changes to canto34 as I make changes to Mettle. I don’t want to have upload changes to canto34, and then download them in Mettle. I just want to develop both.
npm lets you do this by CDing into canto34’s directory and typing
And then CDing into Mettle’s directory and typing
npm link canto34
Magic! npm ‘installs’ canto34 on my machine using a shortcut to my development copy, so that I now have this structure on my disk;
And I can now develop both projects together.
The thing here isn’t that the command line support is good — on its own, that’s pretty dull. The nice thing is now the npm system seems really well designed to get you sharing code, and doesn’t punish you for doing so. You can share libraries as open source, or use them in proprietary projects, or mix the two together, and it feels like npm is your buddy — a little like, I guess, an author feels about an editor; the technical guy that gets your artistry out to the world.
All in all, a very good developer experience