[darcyparker]

Volta shows promise and I like that it's fast. But to me it seems like it will be hard to adopt until it supports `.node-version` file (a working standard among node version managers). For example, while some may want to use Volta, others will likely be using `nvm`. And a project's CI likely uses `nvm`. Volta has `volta` property for `package.json` to pin the node and npm version. That's nice and more specific than the `engines` property which can be a range of versions. But it would be better to keep things DRY and leverage the working standard for how node version managers keep track of the node version. (Otherwise a project has to maintain node version information in multiple places.)

https://github.com/volta-cli/volta/issues/959

[jiofih]

What’s the issue with the engines field? I don’t see any particularly strong reason to not use it.

[charlespierce]

In addition to the points raised by the other comments, a big reason we decided not to use `engines` in Volta is that `engines` can be a range: One of the design goals of Volta is to allow for reliable, reproducible environments, and a range is necessarily not static (new versions are released all the time).

[jiofih]

Semantic versioning was supposed to prevent breaking changes. I guess this is more akin to package-lock.json then.

[charlespierce]

Yeah, conceptually the setting is intended to be closer to a lockfile than a semantic version.

Additionally, even with semantic versions, `engines` is often specified as something like `12 || 14 || >= 16`, so they span multiple major versions, which is where breaking changes can (and do) show up.

[galvin]

The engines field is generally used for package consumers so when you do an `npm install` you know if the package is compatible with your local node version.

Pinning the Node.js version for tools like nvm is used by developers of the package or app developers who want to use the same version of node locally and in production, for example.

[krono]

It functions more like a suggestion than a hard restriction. And, as far as I'm aware, tools such as NVM plain ignore it in favour of their own configuration files.