Use package.json's `engines.node` when no .nvmdrc is present

[JWess]

Deployed applications often specify what version of Node should be used during development and in the deployed environment by using package.json's engines.node field. It would be nice if this tool could use it when specifying a Project folder if it is present instead of adding a .nvmdrc file. Checking in an extra file to the repo, as well as having to remember to keep the node version in sync between two places is not ideal. For instance, let's say I decide my project is moving to v20.11.0. I now have to go update package.json's engines.node and the .nvmdrc file.

Also of note, engines.node can specify a range of versions. When a range is encountered, use the newest installed version within the range.

To recap, it would be nice if there were a solution to specify node versions for projects without having to commit an .nvmdrc file and have the node version specified in multiple places that could potentially get out of sync.

[1111mp]

I don't think they are doing the same thing. Because the engines.node field of package.json is usually used to constrain the range of node versions that the project hopes to apply to, rather than a specific version number. .nvmdrc is just the opposite. It is used to specify a specific node version to run your project. Of course, the version of .nvmdrc must be within the range set by engines.node.

Just imagine, when you newly participate in a project, it has already set the version of node for the project through engines.node in advance. At this time, you only need to install a suitable node version within its scope according to this prompt, and .nvmdrc is for this purpose.

Moreover, it is not ideal to calculate the version of node based on engines.node, because its rules are formulated to constrain a range. It is very difficult to determine the most appropriate version number. For example, we have this setting:

"engines": {
   "node": "^8 || ^10"
}

At this time, I don’t know whether I should use the 8.* version or the 10.* version of node.

For instance, let's say I decide my project is moving to v20.11.0. I now have to go update package.json's engines.node and the .nvmdrc file.

In this case, I would think that your engines.node is set to a specific node version, for example: "~20.0.0". If you do this then you really need to change both at the same time. But as said at the beginning, it is also reasonable.

In general, engines.node is just a constraint to remind you of the range of node versions applicable to your current project. And .nvmdrc can be understood to mean that we have chosen a correct node version for it based on this constraint.

Of course, this is just my own understanding of engines.node. If you have better suggestions, please feel free to put them forward. Please feel free to correct me if my idea is wrong.

Thank you. 🌹

[JWess]

You might be right that engines.node is not the place, but I will say that some cloud environments, Heroku for instance, use that field to specify which Node version should be used in the deployed environment. I think it's uncommon to use a range in engines.node for a deployed application, but very commonly seen in the package.json of an npm package/library.

[1111mp]

Sorry, there may not be plans to support this feature yet. Not only because the rules for parsing engines.node are not clear enough, but more importantly, too much file retrieval logic when running commands will affect runtime performance.

I'll mark this issue as a feature request first, and if anyone else needs this feature I'll implement it. We also ask for your understanding. Thank you so much. 🌹

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.