Using "engines" field as fallback

[nicod-pc]

In #355 is already explained why a new volta field was introduced additionally to the engines field (documentation of npm and yarn). I don't like to replace the volta config but I like to suggest to use the engines field as fallback for the following reasons:

• There are old projects that don't have a volta field. So the system node version is used. Especially old projects run with older node versions. So initially the wrong version is used.
• I also work on projects where the maintainers don't use volta.
  • They may not like to have that in the package.json.
  • Even if they include it, who is responsible for keeping it up to date and in sync with the engines version? Since the maintainers don't use it, they won't keep it up to date. But I contribute to it only sporadically and don't follow all the changes there.
• It would avoid human error if there is only one version, otherwise a version might be overlooked when updating. Especially as the engines version (if using Semver) needs to be updated less often than the volta version.
• Support for Semver would be nice anyway, as we like to get all security patches, we don't get, if it is pinned to a specific version.

[charlespierce]

Hi @iwt-nduesing, thanks for asking! You're right that issue outlines some of the reasons why we don't use engines. I think this comment: #742 (comment) also goes into more details about the technical and conceptual reasons why we chose not to support engines.

Unfortunately, I think those limitations apply equally to using it as a fallback; especially the limitation of how we resolve a version range, given that one of Volta's goals is to allow for repeatable builds. Related, there is ongoing discussion in #282 about supporting a separate file, which could combine with .gitignore for situations where the maintainers don't want to check in a reference to Volta.

[nicod-pc]

I don't agree with the reasoning. At least #282 would solve some of them. Some of my reasons are not solved and weight more in my eyes. But I accept the decision. Thanks for considering and the fast response.

[charlespierce]

The ergonomic concerns about keeping the versions in sync are definitely valid and I wonder if there's a way we can ease up that by providing some command to sync them. It would still require someone to run a command, but there may be a way to make it a one-liner that someone can run as they update engines to re-resolve the pinned Node version.