autopublish your npm modules
At Earnest we recently open-sourced autopublish. It is a small, simple tool. It publishes a local npm module to your npm registry of choice, but only when the module’s current version doesn’t already exist in the registry.
Autopublish is primarily intended for use within a Continuous Delivery pipeline. With autopublish it becomes very easy to set up your CI/CD system to automatically publish a module to the registry after it has passed automated quality checks, but only if a human has also decided to bump the version.
One of the main motivations for creating autopublish was to provide out-of-the-box support for publishing to private registries. It uses the same mechanisms to authenticate with the registry you are publishing to that `npm login` and friends use. This makes it really straightforward to integrate with CI. If you are able to pull down a private module from CI then you should be able to publish a new version of a module via CI.
an appropriate level of automation
The goal of our software systems is not to apply maximal automation. Rather the goal is to apply the appropriate level of automation, allowing humans and machines to work in partnership. Humans do what they are best at — the subtle decision-making stuff — while machines do the “toil” — the rote work and the heavy lifting.[1]
Having your CD pipeline publish a new module for every code change would be a little extreme — not every code change warrants a version bump, and determining the semver level of each change sounds like the sort of subtle-decision making where humans play best. So, I’d argue that fully automating the publishing of your npm modules is too much automation.
On the other hand, asking a human to manually perform all the tasks required in publishing a module whenever a new version is ready would be an inappropriate lack of automation. Humans are terrible at remembering to do things. Additionally humans are terrible at performing rote, repetitive tasks — such as those involved in publishing a new module version — in a consistent way. Sometimes we neglect to run the tests first. Sometimes we publish local changes and neglect to also commit those changes to version control. Sometimes we forget to add a version tag to our git repo.
Things like autopublish in a CI/CD pipeline enable an appropriate level of automation. A human operator has control of when to bump a version, and what to bump it to. The machines take it from there, performing the appropriate steps tasks in a fast, reliable, and consistent manner.
For even greater ease the human operator can use the under-appreciated `npm version` command to automate updating package.json and creating a git commit (and tag!). With `npm version` and a well-appointed CD pipeline at hand releasing a new version of a module becomes as easy as:
$> npm version patch
$> git push --follow-tagsThis meets my personal criteria for great dev tooling — the Principle of Pleasant Surprise. The first time you show someone how to perform a task their reaction should be “Oh. That’s it?!”
[1] John Allspaw’s “A Mature Role For Automation” article series has a great in-depth treatment of this concepts, including references to further research and discussion.
