Today I learned about npm release channels.

Stop breaking things for people using your package and have a more sustainable way of addressing releases by creating release channels.

Using release channels acts as an additional security net to catch mistakes of any kind and adopting good habits early leaves you well prepared for overwhelming success that might follow later.

With release channels, updates can be rolled out in a very controlled manner and by means of an update cycle of your own choosing. For instance, take the Chrome Release Channels:

• Stable
  • Fully tested.
  • Best bet to avoid crashes and other issues.
  • Updated roughly every two-three weeks for minor releases, and every 6 weeks for major releases.
• Beta
  • See what's next, with minimal risk.
  • Updated every week roughly, with major updates coming every six weeks, more than a month before the Stable channel will get them.
• Dev
  • See what's happening quickly.
  • Updated once or twice weekly and it shows what's worked on right now.
  • There's no lag between major versions.
  • Subject to bugs, because it shows what's new as soon as possible.
• Canary
  • Bleeding edge.
  • Released daily.
  • Has not been tested or used.
  • No guarantee that it will even run in some cases.
  • Reports crashes and usage statistics by default.

Support for release channels can be accomplished by means of npm package distribution tags, or dist-tags. In fact, if you ever typed npm i <package> before, you have implicitly used this feature already, because npm uses the latest dist-tag by default.

npm publish --tag=<the name of your dist-tag>

For example:

npm publish --tag=canary

npm i <package>@<the name of your dist-tag>

For example, if the name of my package is supereact, then the command will be:

npm i supereact@canary

npm dist-tag add <package>@<your latest version> latest

For example, if the name of my package is supereact, and the highest version is 98.0.1, then the command will be:

npm dist-tag add supereact@98.0.1 latest

By using a semver pre-release version in combination with a dist-tag, it's possible to release multiple feature branches at the same time. For example:

• Branch master with dist-tag v1.0.0
• Branch feature/1 with dist-tag v1.0.1-feature.1
• Branch feature/2 with dist-tag v1.0.1-feature.2

It's also possible to set the name of the dist-tag in your package.json file by using the publishConfig property. This way you can make sure the correct dist-tag is always set when publishing:

"publishConfig": {
  "tag": "canary"
}

This can be convenient when releasing feature branches.

• semantic-release

• Article with very long title
• npm publishConfig docs
• npm dist-tag CLI docs
• Video tutorial
• semver pre-release version
• Chrome Release Channels

MIT © Daniël Illouz