Use package.json engines version?

[kievechua]

Run nvm use will read local package.json's engines.node and change version accordingly.
Or anyway that auto switch the version.

[ljharb]

Hmm - engines.node is only meant to be advisory, and no part of the node ecosystem uses it for any other purpose. For example, if a package specifies "0.8" that doesn't mean it won't work on iojs or 0.12 - it might be problematic to default the user to 0.8 just because the author hadn't updated their package.json.

I could definitely add this as an alternative, when .npmrc wasn't available - I'm just not convinced it would be a good thing. Also, the engines field can specify semver ranges - so I'd need to use semver to resolve that between the available node versions - which is a dependency that requires node in software that doesn't have node as a dependency.

[assaf]

NPM treats engines.node as advisory, but that's not the only way to use package.json. It's actually very convenient when everyone on the team, the CI server, and production servers all pick the same version, based on package.json. And a huge time saved when shuffling between multiple projects (consulting, microservices, migration, etc).

So it would be of great help if nvm could pick up on the current project's specific choice of iojs/Node.

[ljharb]

@assaf it already can! Just put a .nvmrc file in your project repo, and do a bare nvm install or nvm use in the project directory.

[assaf]

How do you tell .nvmrc to pick the version specified in package.json?

[ljharb]

That's not what I meant - I meant you just manually put a version in that file and commit that to the repo.

[assaf]

That's not what I was asking for. Having multiple files that specify which version of iojs/Node is in use, just means more things breaking because "works on my machine". Common sense is to keep the project DRY and have a single authoritative specification of the version in use.

[ljharb]

Right, I agree with that. The problem is that node.engines in package.json specifies the minimum version a module works with - ie, most of mine say 0.4, but I wouldn't want nvm to use 0.4 by default. By contrast, .nvmrc specifies the version I want to use it with, which is the maximum version it works with - iojs or stable for most of mine.

Thus, since they're for two separate purposes, I wouldn't want to get more DRY than two separate configurations. "Too DRY" can be worse than "not DRY enough".

[assaf]

If you don't like this feature don't use it. I'd like to have such a feature that I will then choose to use for my projects.

[ljharb]

"if you don't like it then don't use it" is not really a good justification for adding any feature to any project. It's nice that you want it, and thanks for offering your thoughts, but:

• I don't think the feature makes sense semantically - in other words, that the package.json "minimum supported version range" field makes sense as a "run it under this one single version of node/io.js"
• Parsing JSON from the shell is prohibitively complex - we can't use any npm modules and would have to use a technique that worked in bash, dash, ksh, and zsh. Can you suggest one?
• The semver range issue I mentioned above.

In other words, even if I thought this was a good feature on its face, there's just no way it's practical, so it simply can't happen.

I'm happy to review a PR in the future if someone can come up with a simple way to achieve it, but I remain opposed on the semantic appropriateness of this feature and would need to be convinced.

[assaf]

I'm most familiar with https://github.com/stedolan/jq which Heroku uses to parse package.json as part their deploy setup. Semver can also solved: https://github.com/heroku/heroku-buildpack-nodejs/blob/master/lib/build.sh#L133

PR would be pointless, we can't even agree that my use case for nvm is even worth keeping this issue open for.

[ljharb]

Yes but that would be an additional dependency to install, which currently nvm requires installing none (simply curl or wget to install node/iojs versions).

If you wrote a small commandline script that did what you wanted and supplied the version to nvm use, that would at least convince me that it's possible in a practical sense.

[assaf]

https://gist.github.com/assaf/ee377a186371e2e269a7

[ljharb]

Thanks, that's great - I'm not stoked on the reliance on a heroku app for semver resolution, and the usual advice in #iojs on freenode is to put the iojs version in engines.node, so I'd expect that to be supported.

nvm_json_extract looks solid tho, even though it's a bunch of support functions.

Currently, we have nvm-exec - what would you think about adding a new executable file to the repo that, when run, prints out the contents of engines.node or engines.iojs (and perhaps picks intelligently by default, and can be overridden to only look at a provided field)? Then at least, you could do nvm use $(nvm package-json-version) or something, and that'd be a step in the direction you want, without running afoul of my semantic concerns.

[assaf]

If you set engines.node to 1.6.2 it will call nvm use v1.6.2. If you set engines.iojs to 1.6.2 it will call nvm use iojs-v1.6.2. If you set engines.node to 0.12.0 and engines.iojs to 1.6.2, it will call nvm use iojs-v1.6.2. It follows how people use engines today to set target versions.

The semver version is used for resolving ranges. Heroku maintains it as part of their build infrastructure, a front-end to nodejs.org/iojs.org, so it's already used by many of the people who will find this feature useful, to develop and deploy against the same version.

However, if you need repeatable builds, you should set the specific version in package.json and only that version will be used. No substitutions. And no dependencies on 3rd parties.

This works. It allows you to use package.json to specify which version of io.js/Node you want your code to run against. And it's based on a common deployment pattern (Heroku but also other PaaS influenced by them).

It does not deprecate or change existing functionality. It should still be possible use .nvmrc, but this could co-exist for developer who prefer to set the engine version in package.json and have it picked up on local, CI, and production.

[ljharb]

Awesome, that behavior makes sense to me, thanks for clarifying.

Currently, if I don't have a .nvmrc and run nvm use, I get an error and help output - adding an additional fallback would be a breaking change (which isn't a problem, just worth noting).

[assaf]

I don't think it's a good idea to break current behavior. Could be a new command, or use an alias, maybe nvm use package?

[ljharb]

Interesting idea! As an alias, it'd have to be overridable, just like node/stable/unstable/iojs are, but maybe that's OK. That would certainly make it work with every nvm command seamlessly.

[assaf]

Alternatively, it could be a path, so nvm use <version | file> first looks up an alias with that name, if that fails, it looks up a file with that name. That way, it could be a shell script somewhere inside the project, pointing to the package.json in a parent directory.

And if you're in a directory that contains a package.json, nvm ls could also list that version, so you would see:

package.json -> iojs-v1.6 (-> iojs->1.6.2)

[focusaurus]

+1 to @assaf's request here. I was in the middle of coding stuff into my shell files to do exactly this when I discovered this issue. I'd also like to note that from my perspective there are big, important differences between an application and a reusable module, and many things in the npm ecosystem fail to recognize this, causing me much frustration. This is an application-driven feature request where your code is the first thing the node binary loads, and I think engines.node and engines.iojs are good ways to express an application's chosen runtime version.

[jamsyoung]

I ran across this issue when I had the same thought that it would be convenient that nvm use would just pickup whatever I have in my package.json. After reading the comments here I agree with @ljharb and can see that this will likely cause more problems than it is worth since most people probably do not use the package.json engines data like I do with CI to indicate what version of node to install on the build agent.

I would like share that you can still use the info from package.json with nvm by utilizing jq as follows:

$ nvm use $(jq -r .engines.node package.json)

And if you don't have the version installed yet, you can use the same concept with nvm install

$ nvm install $(jq -r .engines.node package.json)

Yeah, thats a lot of typing, but you could alias it if you really wanted to.

[focusaurus]

A version of grabbing engines.node without the external dependency on jq is: node -p -e 'require("./package").engines.node'

[ljharb]

Although that won't work unless you already have node installed, which isn't something to rely on when using a node version manager :-)

[bettiolo]

Is anyone actively working on a command line nvm < use | install > package.json?

[hurrymaplelad]

FYI, nodenv has a passable plugin api copied from rbenv. It was pretty straightforward to build a plugin to parse package.json engines after @assaf did all the hard work :)

We're looking at using sh-semver to evaluate semver ranges without a network call or a node dependency.

[patcon]

Just wanted to chime in to say that I agree with @assaf's original sentiment that locking to specific node version should be encouraged -- lack of version constraint is a good thing imho, should folks choose to use engines.node

[acjay]

👍 To the original suggestion. It's super helpful in having a smooth process for getting people up and running on a project locally, especially from zero. I'm imagining a workflow that would be as simple as:

• clone project from Github
• install NVM
• nvm install package.json or something, which would install the correct version of Node and NPM for the project and npm install all the modules
• npm start

Even better, if there were a way to nvm install-repo git@github.com:..., we could get rid of step 1.

[zoobot]

Thanks for reassuring me of the path to sanity for this.
My current company has the CI that checks package.json version but most repos don't have .nvmrc yet so since a few days ago I've been adding them, with a ton of rabbitholes and PRs on unrelated code fixes to get the commits to work.

Thanks for linking the PR!!
Fingers cross that this will happen soon:

1. check for local .nvmrc
2. check for package.json "engines"
3. check for inherited .nvmrc
4. use default, if present
5. error and show help text

Or ideally, if it could just use package.json "engines", that would stop the need for having the version in .nvmrc and we wouldn't have to add it to all our repos.

[khaledM1]

This will be a nice addition to nvm since every project has a project.json file

Every tool likes to add more unnecessary dot files :(

[bettiolo]

I am glad to see that there is still interest to look into this, I hope we get a solution soon!

[lautarodragan]

+1 to this feature request!

My 2c: my current company has an engines field, which is useful because it warns you on npm ci if you're using a node version that falls out of this range.

Since this warning is important, and for other reasons, we can't remove the engines entry in package.json. Hence, adding a .nvmrc would be duplicated data — which is problematic, because if we updated one, we'd need to remember to update the other.

We could solve that problem with automation — a step that makes sure .nvmrc and engines.node are the same in CI, but that seems overkill.

nvm use (with no further args) consuming package.json's engines.node field could be opt-in if we needed to make sure this is a backwards-compatible change.

For now, I'm sticking with jamsyoung's suggestion, nvm use $(jq -r .engines.node package.json), but adding this to the company docs can be controversial because not everyone has jq installed.

[ljharb]

@lautarodragan indeed, "automation" is how that's been solved at all of my past employers.

(re jq, you can use npx json instead, i believe, and it should work the same)

[prerakhere]

(My query may sound a bit off topic and naive)
In my project, I have updated node version in .nvmrc file to latest LTS node version - 18.14.2 (previously it was some other version)
The template that I was using to spin up the project had engines.node version range >=14.15.0
Query 1: On updating .nvmrc node version, is engines.node version supposed to be updated to some other value automatically / manually?
Query 2: Other node-like dependencies, for example, @types/nodes(I am using typescript) version is 14.14.25. Is that also supposed to be updated to some v18 version?
Query 3: if .nvmrc is guiding the project's overall node version, why are other (node)dependencies in package.json not updating themselves? What is the overall process like?

Thanks

[faisalraya]

@ljharb is there was a way use to npx json inside .nvmrc instead of running it as a command every-time? and you're right. npx json works like jq

[ljharb]

nvm can't assume that node is already available, so it can't run npx.

[ysmood]

Here's my solution, supports engines and ranged semver, maybe nvm can borrow some ideas from it:

https://github.com/ysmood/use-node

[tomzaku]

I'm following this simple approach

alias nv="cat package.json | grep '\"node\": ' | grep -o '[0-9.]*'"
nvm use $(nv)

[ljharb]

Careful with that; JSON doesnt require a space after the colon, and npm dist-tags i believe can also be used there.

[wszydlak]

For anyone interested, i created package called nvm-auto that uses version from engines field, it also supports semver ranges.

https://www.npmjs.com/package/nvm-auto

Simple usage:

npx nvm-auto

Works for nvm and nvm-windows

[vegerot]

@maintainers tl;dr. If I submit a patch that adds this feature, would you land it?

[ljharb]

@vegerot not necessarily, or else the "pull request wanted" label would be on the issue. Additionally, see #1535..