Volta: Support pinning major version

Created on 22 Dec 2020 · 5Comments · Source: volta-cli/volta

I don't really care about minor and patch changes of node or npm, or even yarn, since they won't contain any breaking change. So, I would like to use something like:

{ 
  "volta": {
    "node": "^14.15.3",
    "npm": "^7.3.0"
  }
}

Where it follows the npm syntax for installing the latest minor release of node@14 or npm@7. However, it could also have a simpler syntax:

{ 
  "volta": {
    "node": "14",
    "npm": "7"
  }
}

Which is similar to volta install node@14 and volta install npm@7.

Source

felipecrs

Most helpful comment

While it's true that semver in theory provides guarantees about the compatibility of different releases, in practice there are always exceptions. One example is a new version of Node could introduce a bug in your tooling that causes things to break. With a relative specifier in package.json, two members of a team (or a member and the CI server) might have different minor versions of Node, resulting in a "works on my machine!" situation. One of the goals of Volta is to prevent those kinds of issues by making the environment fully reproducible.

A concrete example of this is discussed in this PR: https://github.com/yarnpkg/yarn/pull/8190 - Even though it's a minor version change (from Node 12.13.0 to 12.16.1), the changes result in Yarn failing to run postpack scripts.

I like the suggestion on how to avoid performance issues by preventing refetching every time, however Volta operates under a different mental model than many similar tools. Specifically, with Volta there is no concept of a "current version" of Node. Instead, each time you run a command, Volta detects the context in which you are running and executes the appropriate versions. So in our case, there wouldn't be anything to compare the Semver range with, instead we would need to re-evaluate it on every run, with all the performance penalties that implies.

charlespierce on 22 Dec 2020

👍2 😕1

All 5 comments

Hi @felipecrs, thanks for the suggestion! This is closely related to another suggestion, using the engines section in package.json to pick the version. We considered that and investigated it early on in developing Volta, and ultimately decided against it for reasons described in this comment: https://github.com/volta-cli/volta/issues/742#issuecomment-631588143

For ease of use, we do have the volta pin command, which accepts a range version (e.g. volta pin node@14). What it will do is resolve that version _right now_, and pin the exact version it finds in your package.json so that it won't change in the future (without you explicitly changing it). That way you can have the speed and reproducibility guarantees while at the same time not having to look up the specific minor & patch versions needed.

charlespierce on 22 Dec 2020

Hi @charlespierce.

This discussion could be endless if we reach the "it might not be a good idea" phase. Be it a good idea or not, semver guarantees that no minor and patch releases have any breaking changes, therefore I don't want to keep my project using an old revision of Node just because I forgot to run volta pin node@14 every day to watch for changes. Also, being a good idea or not, npm has adopted it.

Volta can work this way:

Given:

{ 
  "volta": {
    "node": "^14.15.3",
    "npm": "^7.3.0"
  }
}

Volta checks if the current version of Node is higher than or equal to 14.15.3, considering minor and patch releases. If yes, there is no need to install a new Node. Otherwise, Volta installs the latest minor/patch release of Node 14.

felipecrs on 22 Dec 2020