Hello fxos, I wanted to start a conversation about versioning of our npm packages. Over the weekend I was bit by an issue with the way we require and version packages, and I'd like to work to resolve these issues.
Semantic versioning [1], or semver, is core to the way packages are installed in npm. The default behavior for npm when saving a dependency is to allow version ranges of a package to be used if available. Take this dependency in a package.json: "express": "^4.0.0" The caret represents a major version range; anything 4.0.0 and greater, up to but not including 5.0.0 can be used. While this idea is great in theory, it turns out to cause a lot of problems if semver isn't followed properly. If someone releases a breaking change to express and only bumps the minor version, it has the potential to break everyone in the 4.x.x line of express. There are a few ways to solve this. 1. Packages should probably stop using version ranges for their dependencies. By using the --save-exact flag when installed, e.g. `npm install --save --save-exact express`, a package dependency can be pinned to a specific version. You can make this the default behavior when saving with: npm config set save-exact true 2. Follow semver religiously; update the patch version with bugs, the minor version with features, and always update the major version if there is a breaking change. 3. Don't allow pre-release packages to become dependencies with pre-1.0.0 versions. I notice in a lot of our packages, many have versions that are pre-1.0.0. Without pinned versions, it's a good probability that more breaking changes are released by just incrementing the minor version. This is fine during development, but once that package becomes a dependency of another, it's time to make it 1.0.0 and follow semver correctly. 4. Don't depend on packages using "*". This angers the gods and many kittens are sacrificed to appease them. Starting these practices would be a big help in reducing tough bugs from poor versioning, although it won't help much for sub-dependencies. Shrinkwrapping could help there, but that's another conversation. If you have an npm package used by our projects, please have a look at their versions and see if you can help us by ensuring your versions aren't harmful. :) [1] http://semver.org/ Thanks! Eli Perelman
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
