The default assumption for distributing a Node.js module is to publish it in the public npm registry. It's a simple declaration in the package.json, and then you tell your customers to simply type "npm install". The public npm registry takes care of the details, and you can even use versioning to make sure your customers use tested module versions. But what if you don't want to publish modules in the public npm registry? Maybe your modules are proprietary, or maybe the modules are too intertwined with a parent product to be of general use?
Click here for more Node.js programming advice
The npm registry is getting filled with modules, some of which are helper modules for specific parent products. Ideally, modules listed in the public npm registry are of general use and can be used with any project. But, browsing the public npm registry we see many modules that are specific to a certain parent product.
An example, picked at random, is "assemble-markdown-data" whose description reads "An Assemble plugin for automatic parsing of markdown." Assemble is some kind of static site generator for use in grunt.js, so we have a plugin for Assemble which is taking up an entry in the npm registry. While the npm registry can probably handle zillions of entries, it means anyone looking for markdown modules will have that many more modules to evaluate. Oh, and to be fair, for my own product, AkashaCMS, I published all the plugin modules into the npm registry. I'm looking at myself as much as the other people, and wondering if this is the best idea.
For privately published modules, the recommendation is to run a private npm registry. This lets you locally cache stuff from the public npm registry, but also is a place to publish company-private modules.
It's not necessary to run a private npm registry, and it's not necessary to publish all your modules into the public npm registry.
The default preferred package.json usage, for declaring dependencies, results in every module being published into the npm registry. The default best practice for the the "dependencies" field in the package.json is:
{ "dependencies" :
{ "foo" : "1.0.0 - 2.9999.9999"
, "bar" : ">=1.0.2 <2.1.2"
, "baz" : ">1.0.2 <=2.3.4"
...
}
}
The version number specifiers reference the package.json version in the npm registry. It's so easy to just go ahead and write the dependencies this way, and then publish all the dependencies into the npm registry. As I said, that leads to bloat of the npm registry and the rest of us have to evaluate more and more modules before finding the right candidate.
But there's another way, because the dependencies format allows you to specify a URL or git repository reference or even a github reference. It's all specified in the npm package.json documentation, so let's do a quick review.
First off is a version number dependency, as shown above. The version numbering scheme is documented in the semver page. These always refer to modules published in the npm registry.
Next is to simply specify a URL.
{ "dependencies" :
{ ... "asd" : "http://asdf.com/asdf.tar.gz" ... }
}
The documentation says "You may specify a tarball URL in place of a version range. This tarball will be downloaded and installed locally to your package at install time." That's simple and straightforward. Since it says "tarball" that means it supports .tar.gz bundles, and perhaps doesn't support other packaging formats like .zip. That's fine with me if it only supports .tar.gz but those other packaging formats do exist because other people prefer them, and it would be nice if the documentation explicitly said so.
Next, there are two ways to specify git URL's. One is specifying a full URL, that includes a "#tag" reference to a commit tag, branch tag, etc. The other is specifying the simple "user-name/repository-name" reference for a github repository.
What this means is Node.js developers have three ways of listing a dependency to a module which is storable in a public location, without forcing you to publish the module to the public npm registry. Further these methods let you keep a module private inside your company, without having to run a private npm registry, and without publishing the module in a public location.
You don't have to give up the module version numbering support either. Both the "tarball URL" and "git repository URL" methods let you specify a version number to reference.