[Feature Request] Support .nvmrc for pnpm env

[kylemh]

Just learned about pnpm env from this Twitter thread

• I'd be willing to implement this feature (contributing guide)

Describe the user story

If I have an .nvmrc file, I'd like to be able to run pnpm env and have that Node version automatically install (if needed) and be switched to.

[xeho91]

If this feature request would pass, how about using the engines key from package.json, where we can specify node version, instead of another file .nvmrc?

{
  "engines": {
    "node": "16.14.2"
  }
}

[zkochan]

No, we cannot use the engines field because if you publish such package and you will install it with 16.14.3, you'll get a warning. Or even a crash.

[tsndr]

Missing support for .nvmrc or an equivalent file is the only thing keeping be from switching to pnpm.

[privatenumber]

Alternatively, a node-version-file rc option like @actions/setup-node.

[zkochan]

Why should pnpm read from .nvmrc? pnpm reads settings from .npmrc.

You can specify the node version via use-node-version in .npmrc.

Added an explanation about it to the docs: pnpm/pnpm.github.io@5bd1b5c

[privatenumber]

It doesn't necessarily have to be .nvmrc, but there seems to be a convention to have a file containing just the Node.js version amongst popular Node.js managers (eg. nvm, fnm, n, @actions/setup-node, etc).

If it's in a file of its own, it can either be cat'd into the "install Node" command or symlinked to the appropriate config file path used by other Node.js managers.

[adam-zielonka]

Hello, you're missing also .node-version file that it use for some node version managers.

It's so stupid that there is no one way to do it.

[weyert]

and .tool_versions for asdf

[privatenumber]

I think it would be fine if pnpm could just support one file format.

Every other file name can be supported via symlink.

[adam-zielonka]

I wrote the message before try this node version management feature. I change my mind. It is not necessary to support other ways for determining node version, because it is invisible for developers. I just added node version in pnpm way in one project and I am sure that most of my colleagues will not realise about change, when they start working on this project. And CI it's just simpler, one image with pnpm to maintenance.

[privatenumber]

If you're using GitHub Actions, here's a relevant CI limitation with pnpm setting up Node.js: pnpm/action-setup#70

[callumlocke]

Any decision on which file would be best to use for this - .npmrc, .nvmrc, .node-version?

And would it work with pnpm env use without args? Or just pnpm env?

[shadowspawn]

For interest, node version managers and products supporting .node-version: https://github.com/shadowspawn/node-version-usage

[Kytech]

NVM is quite popular, so supporting .nvmrc is probably worthwhile. I think .nvmrc and .node-version are the two most popular files used for specifying a node version.

And would it work with pnpm env use without args? Or just pnpm env?

I'd think it would make most sense to have the behavior of reading from a node version file be for a no-arg use of pnpm env. (Think nvm's usage pattern). Specifying argument(s) should be for cases where you'd want to override the behavior or node version that the project specifies in its file. I know its very common for users of node version managers to use a shell integration that will auto-switch the node version if they enter a folder with a node version file. This is also another point in favor of using a separate node version file instead of just in the .npmrc file - this would make it much easier for people to adopt pnpm for an auto-switch shell integration script.

[sschuberth]

how about using the engines key from package.json, where we can specify node version

That would be #7211, BTW.

[sschuberth]

No, we cannot use the engines field because if you publish such package and you will install it with 16.14.3, you'll get a warning. Or even a crash.

I don't get why pnpm env use can't be taught to look at a package.jsons engines.node instead of getting the Node version from the command line...