CODEWITHSUNDEEP
node.jsnpmsemantic-versioning
Jonathan.Brink
Jonathan.Brink

Reputation: 25373

Use latest major version

In my JavaScript applications I may be declaring a few dozen dependencies in my package.json file.

It would take a while to go through each one of those dependencies and see which version they are on.

I just want to say: use the latest major version, but not the bleeding edge.

As an example, with a tool like Git I don't usually care about taking changes at the patch-level but if a new major release comes out I will want it.

Is there a similar concept when specifying the version of a npm module?

Upvotes: 8

Views: 20737

Answers (2)

Burt_Harris
Burt_Harris

Reputation: 6854

Using npm i -S <pkg> should normally do the right thing.

A few caveats:

  • The above assumes if you are taking a runtime dependency on <pkg>. In installing a developer tool (like grunt) use -D or -G instead of -S.

  • Semantic versioning rule 9 says that publishers MAY identify pre-release versions using a suffix like -beta. Npm depends on it, so if package publisher FAILS to do it, you might take a dependency on a pre-release package without knowing it. Sophisticated npm publishers should know better, and sophisticated npm consumers should check the documentation.

  • A major version is '0' indicates the package is still in initial development, and the package SHOULD NOT be considered stable. (Semantic versioning rule 4.)

  • Consider using npm dist-tag ls <pkg> to see if there is some package-specific tag that identifies your intent better than latest. If so, use npm I -S <pkg>@<tag> to track that tag.

You can always use npm outdated to check if you dependend directly on a package with a new major release might want to consider upgrading to. It is by-design that major version upgrades do not happen automatically.

Upvotes: 3

ceejayoz
ceejayoz

Reputation: 179994

NPM packages (theoretically) use SemVer.

In SemVer, packages get a version number of X.Y.Z.

Z indicates bug fixes. Y indicates new features without changing existing ones. X indicates a major version that breaks backwards-compatibility.

Doing npm install --save <package> will result in a version string in your package.json like ^2.3.9, which means "anything in the 2.* range greater than or equal to 2.3.9". This'll mean you get bug fixes and non-breaking new features, but you won't unexpectedly be updated to a version 3.0.0 that breaks your application.

Note: I say "theoretically" because not everyone sticks to SemVer's ideal. You may find a 2.3.9 -> 2.3.10 upgrade that breaks stuff at times. Tests are handy here.

Upvotes: 5

Related Questions