Volta: Default to use "engines" value as pinned or have configuration to use "engines" value

Created on 20 May 2020  路  2Comments  路  Source: volta-cli/volta

Hi there, maybe I'm missing something obvious but for pinning Volta in a project, why doesn't Volta simply use the values from the engines by default?

We have projects with package.json files contain:

  "engines": {
    "node": "10.16.0",
    "npm": "6.9.0",
    "yarn": "1.16.0"
  },
  "volta": {
    "node": "10.16.0",
    "yarn": "1.16.0"
  },

Could we leave out the "volta" config when the "engines" field exist or do something like:

  "engines": {
    "node": "10.16.0",
    "npm": "6.9.0",
    "yarn": "1.16.0"
  },
  "volta": {
    "useEngines": true
  },

And in this scenario it'd ignore the npm value safely?

Most helpful comment

Hi @chrisirhc, there are actually a couple of reasons we avoid using engines, one technical and one conceptual.

First, from a technical standpoint, the engines key supports semver ranges (like 8.* || 10.* || >= 12), while the volta entries need to be a specific version. We do this for performance and so that the environment is repeatable. We have the ability to resolve a version requirement, but doing so would require that we re-evaluate the setting in engines on every execution (which could require a network call) and it would mean that a new version being published would change the active version of Node right out from underneath you. We chose instead to make the version itself pinned so that changing it requires an active step on the part of the team.

Next, conceptually, the two fields represent something _slightly_ different: engines is used to indicate on which versions your package can _run_, while volta is used to specify the versions used to _develop_ your package. Though there's natural overlap, the two are distinct.

For those reasons, we ultimately decided against trying to re-use the engines key. This does lead to a bit of duplication, as you noted, but we felt it was best way forward at the time.

All 2 comments

Hi @chrisirhc, there are actually a couple of reasons we avoid using engines, one technical and one conceptual.

First, from a technical standpoint, the engines key supports semver ranges (like 8.* || 10.* || >= 12), while the volta entries need to be a specific version. We do this for performance and so that the environment is repeatable. We have the ability to resolve a version requirement, but doing so would require that we re-evaluate the setting in engines on every execution (which could require a network call) and it would mean that a new version being published would change the active version of Node right out from underneath you. We chose instead to make the version itself pinned so that changing it requires an active step on the part of the team.

Next, conceptually, the two fields represent something _slightly_ different: engines is used to indicate on which versions your package can _run_, while volta is used to specify the versions used to _develop_ your package. Though there's natural overlap, the two are distinct.

For those reasons, we ultimately decided against trying to re-use the engines key. This does lead to a bit of duplication, as you noted, but we felt it was best way forward at the time.

Closing as it's been a few weeks. Feel free to re-open if you have other questions!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

felipecrs picture felipecrs  路  5Comments

elwayman02 picture elwayman02  路  4Comments

Stanzilla picture Stanzilla  路  3Comments

uasi picture uasi  路  3Comments

timsuchanek picture timsuchanek  路  4Comments