Enforcing node/npm versions during local development

[markcellus]

I've opened an npm issue in the community but is it worth exploring doing an RFC to enforce a node/npm version during local development only when working on client-side npm packages? Very frequently, client side packages only need to enforce versions locally since they usually distribute files that are transpiled for the browser.

We've tried using the npm engine-strict for this purpose but that enforces versions at the consumer level, which we don't want. As a workaround, we are stripping the engines field as a pre-publish step which solves the issue but this seems pretty hacky and I'm not sure what negative implications this may have.

[isaacs]

I can see the value in this. How would you imagine it working?

Just a thought, have you considered using something like nave for this? (Nvm is more popular as version manager, but I imagine it might also be a bit harder to use as a devDependency in this way.)

{
  "name": "my-frontend-project-that-uses-node-v10",
  "version": "1.2.3",
  "scripts": {
    "prepare": "nave use 10 node build-my-stuff.js"
  },
  "devDependencies": {
    "nave": "^3.2.0"
  }
}

Of course, this will require that you have Bash installed in your dev environment.

[markcellus]

Nave seems pretty cool, but we have a ton of teams that are already using nvm. To get them all to switch to using this wouldn't be possible, unfortunately. But I did find check-engine which checks if the developer has the proper node/npm version installed locally, but it uses the engines field from the package.json which gets imposed onto its consumers 😩.

But glad that you think something like this will be useful! I'm thinking we can add something like a devEngines field similar to the engines field in package.json that npm enforces only on local development when any npm commands are attempted. What do you think?

[isaacs]

There's no reason why people need to stop using nvm, or switch to nave full time. If it's a dev dep, and included in the scripts, it'll Just Work, no matter what they use for their day to day.

When would devEngines be checked?

[travi]

if your team is already using nvm, have you found/tried avn? it still doesn't enforce, but automates enough to make it harder to forget to use the correct version. i've found it to be very effective on my team.

[ljharb]

I'm a bit unclear on the use case here - this is for an npm package that does not distribute a main, only a browser field, and thus only cares about the node version for local dev?

[isaacs]

Oh, another option is to add node as a devDependency at some specific version. Then running node foo.js in a package script will pick up the bin for the version range you specify.

[markcellus]

oh wow, @isaacs I guess I never thought of that. That would essentially be the same thing as what I'm proposing and we don't need to add any new deps into our workflow!

[markcellus]

@isaacs couple of questions though...

1. What would happen if the node dep in devDependencies isn't installed, but npm is? and
2. Would that only work when running package scripts? or any npm command (e.g. npm install, npm update, etc)

[isaacs]

npm modifies the PATH environment variable when running lifecycle scripts (ie, the "scripts" in package.json), to include ./node_modules/.bin/ as the first item where executables are found. That's why you can do things like install tap or jest as a local dep, and then your test script will be able to run them, even though you maybe can't run them in your normal shell.

If you put the node module as a devDependency, then it'll be installed when you're doing local dev. If it's installed, there'll be an executable at ./node_modules/.bin/node pointing to it. If a script runs node foo.js, or has a script starting with #!/usr/bin/env node, it'll pick up the one at node_modules/.bin/node one instead of the one in /usr/local/bin or whatever.

I'm not sure why you'd list npm as a devDependency in a project. Presumably you need npm to install its deps, so you'd already have it?

npm itself will still run with your global node. But the package scripts will run with the bundled node.

The downside is that you need another copy of node in your project. If you have a lot of projects, that might get annoying. The nave or avn approach only keeps one copy of each version.

[markcellus]

npm itself will still run with your global node. But the package scripts will run with the bundled node.

Yeah but I would like to enforce the node version and the npm version. If the global npm version would still be used when running npm run scripts, that wouldnt really solve the original issue right?

[isaacs]

you could do something like this:

{
  "devDependencies": {
    "nave": "3.2.0"
  },
  "scripts": {
    "test": "nave use 12.11.0 npm run test-actual",
    "test-actual": "do something"
  }
}

Since nave installs both node and npm, the test-actual script would be run with the npm version bundled with node 12.11.0.

[markcellus]

Yeah I could do that. But does it run when npm install is ran? Or npm update or npm ci? I'd like npm and node versions to be enforced when any npm command is attempted.

As for custom npm run scripts, i'd have to prefix every single command with nave. I appreciate the solution but just seems like more work and complicates things more than the workaround we're already doing.

[isaacs]

Yeah, it'd really only be a solution for specific scripts that you'd want to be run with a given version of node/npm. It wouldn't change npm install or anything else. If you want that to be in sync, you have to make the whole environment match.

[markcellus]

Yeah, is a proposal for something like devEngines possible? 🙂

[vvo]

Hi there, indeed being able to control Node.js/npm version is very handy. In any environment in fact, not just dev. Anytime Node.js/npm is used in my project I want the exact same versions to be used.

For example, when a build happens in GitHub actions/Vercel/CI, I want a specific Node.js and npm version to be used.

To control Node.js version, most build systems are now reading the .nvmrc file which is great. And requiring devs to use nvm is fine too as it's very common.

To control npm versions I am not sure what is the solution besides adding npm install -g npm@x and maintaining this over multiple files (README, CI.yml, package.json).

Using Yarn you can do something like this:

yarn policies set-version 1.13.0

When ran inside a project, it:

• downloads a full build of Yarn in a single file and store it in .yarn/releases in your project
• adds yarn-path ".yarn/releases/yarn-1.22.5.js" to a local .yarnrc
• force any installed version of a Yarn cli to use the cli from .yarn/releases

This is handy because it enforces which version will be used every time the command "yarn" (no matter its version) will be launched.

Not saying we should do the same (policies seems too generic for this feature). Just wanted to provide some feedback from a longtime yarn user willing to switch back to npm.

PS: Being able to control an npm version independently from the Node.js version is also very practical since new npm versions are published without new Node.js versions. And there are sometimes new npm features you want to use (like workspaces).

[markcellus]

Can any of the contributors give an update on their position(s) on this? Would be great to know if this sounds feasible to the npm contributors or if there are any other ideas of how this can be implemented or resolved.

Specifying an engines.node field in package.json has been causing confusion for the consumers of our packages, so we've removed them. But we'd still like to enforce specific node versions during development to enforce certain node versions when contributors are running our projects locally.

For instance, contributors of our projects tend to use either Node 14 or 16 recently. But 16 refactors the package-lock.json, so we need to enforce one of the two versions to prevent the lock file from bouncing back and forth, whenever new contributors open a PR after running npm i on the project.

[ljharb]

Since RFCs aren't a thing any more, i put up npm/cli#7253. What are your thoughts?

[markcellus]

@ljharb - thanks a lot for your attempt at adding this as a feature! 🚀

Looks like @wraithgar and @darcyclarke had added some helpful insight in that PR and ended up closing the issue in favor of nodejs/node#51888.

I must admit that I don't have much context into the npm ecosystem. I looked at nodejs/node#51888, which seems like a great feature. But I'm struggling to see how the new packageManager would resolve the ask in this discussion. Can anyone respond with any context on exactly how the packageManager solves this? Thanks for any information!

[darcyclarke]

You are right that the packageManager field does not handle your usecase & I'm a bit concerned that the discussion around devEngines has veered in that direction over at openjs-foundation/package-metadata-interoperability-collab-space#15

Appreciate any insights you can share in that thread for the people involved to understand your real-world usecase.