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?
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!
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
engineskey supports semver ranges (like8.* || 10.* || >= 12), while thevoltaentries 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 inengineson 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:
enginesis used to indicate on which versions your package can _run_, whilevoltais 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
engineskey. This does lead to a bit of duplication, as you noted, but we felt it was best way forward at the time.