PNPM is (still?) not correctly identifying the node version

[arkanes]

pnpm version:

7.9.5

Code to reproduce the issue:

pnpm install

Expected behavior:

installation proceeds as normal

Actual behavior:

 ERR_PNPM_UNSUPPORTED_ENGINE  Unsupported environment (bad pnpm and/or Node.js version)

Additional information:

• node -v prints:
• v18.8.0
• Windows, macOS, or Linux?:
  Windows 10

This is the same issue as #4203 and was either never fixed or has regressed.

This can be reproduced by downloading the 7.9.5 version from github releases and running pnpm install twice. See attached console log

D:\dev
λ mkdir repro

    Directory: D:\dev

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----           8/25/2022  5:19 PM                repro

D:\dev
λ cd repro
D:\dev\repro
λ Invoke-WebRequest https://github.com/pnpm/pnpm/releases/download/v7.9.5/pnpm-win-x64.exe -OutFile pnpm-win-x64.exe
D:\dev\repro
λ .\pnpm-win-x64.exe --version
7.9.5
D:\dev\repro
λ .\pnpm-win-x64.exe create svelte@latest test
../../.pnpm-store/v3/tmp/dlx-18352       |   +5 +
Packages are hard linked from the content-addressable store to the virtual store.
  Content-addressable store is at: D:\.pnpm-store\v3
  Virtual store is at:             ../../.pnpm-store/v3/tmp/dlx-18352/node_modules/.pnpm
../../.pnpm-store/v3/tmp/dlx-18352       | Progress: resolved 5, reused 5, downloaded 0, added 5, done

create-svelte version 2.0.0-next.162

Welcome to SvelteKit!

This is beta software; expect bugs and missing features.

Problems? Open an issue on https://github.com/sveltejs/kit/issues if none exists already.

√ Which Svelte app template? » SvelteKit demo app
√ Add type checking with TypeScript? » Yes, using JavaScript with JSDoc comments
√ Add ESLint for code linting? ... No / Yes
√ Add Prettier for code formatting? ... No / Yes
√ Add Playwright for browser testing? ... No / Yes

Your project is ready!
✔ Type-checked JavaScript
  https://www.typescriptlang.org/tsconfig#checkJs

Install community-maintained integrations:
  https://github.com/svelte-add/svelte-adders

Next steps:
  1: cd test
  2: npm install (or pnpm install, etc)
  3: git init && git add -A && git commit -m "Initial commit" (optional)
  4: npm run dev -- --open

To close the dev server, hit Ctrl-C

Stuck? Visit us at https://svelte.dev/chat

D:\dev\repro
λ cd test
D:\dev\repro\test
λ pnpm install
Packages: +169
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Packages are hard linked from the content-addressable store to the virtual store.
  Content-addressable store is at: D:\.pnpm-store\v3
  Virtual store is at:             node_modules/.pnpm
Progress: resolved 190, reused 169, downloaded 0, added 169, done

dependencies:
+ @fontsource/fira-mono 4.5.9
+ cookie 0.4.2 (0.5.0 is available)

devDependencies:
+ @sveltejs/adapter-auto 1.0.0-next.66
+ @sveltejs/kit 1.0.0-next.442
+ @types/cookie 0.5.1
+ svelte 3.49.0
+ svelte-check 2.8.1
+ typescript 4.7.4
+ vite 3.0.9
D:\dev\repro\test
λ pnpm install
Lockfile is up to date, resolution step is skipped
 ERR_PNPM_UNSUPPORTED_ENGINE  Unsupported environment (bad pnpm and/or Node.js version)

Your Node version is incompatible with "/@sveltejs/kit/1.0.0-next.442_svelte@3.49.0+vite@3.0.9".

Expected version: >=16.9
Got: v14.19.2

This is happening because the package's manifest has an engines.node field specified.
To fix this issue, install the required Node version.
D:\dev\repro\test
λ node -v
v18.8.0

[beeb]

Experiencing the same on macOS and pnpm 7.9.5.

Regardless of my env use --global setting, it's always using v14.x

[perfStack]

Experiencing the same on Arch linux and pnpm 7.9.5.

Steps to fix :-

1. Created .npmrc with use-node-version=18.8.0
2. ran pnpm i

output:

Fetching Node.js 18.8.0 ...
Node.js 18.8.0 is activated
  $InstallDir/pnpm/node -> /home/$User/.local/share/pnpm/nodejs/18.8.0/bin/node

Fixed the issue for me.

[hoomp3]

experiencing the same issue in macOS and pnpm 7.11.0. the above setting fixed it.

[AdriVanHoudt]

I also had this issue

• pnpm version 7.14.2 (installed via homebrew on macOS 13, but updated over time with pnpm add -g pnpm)
• run pnpm env --global 18
• node -v returns 18
• commands ran via pnpm give engine warnings
• but things like pnpm node run the correct node version but still print the warning

Fixed the issue by running pnpm add -g pnpm

[pete-willard]

The same happened to me on pnpm v7.26.0. I am on Manjaro Linux. I must have had node v14 installed via nvm at some point. Setting the exact node version in .npmrc helped. Installing pnpm -g also helped.

[jcc1997]

The same happened in windows on pnpm v7.26.0. And can't run pnpm add -g pnpm.

[ZYinMD]

Same problem on Windows v7.27.0 but can't solve by pnpm add -g pnpm because of #5700.

#5700 suggests using iwr https://get.pnpm.io/install.ps1 -useb | iex as a workaround to update pnpm, but that doesn't solve this node version issue.

[brxken128]

Using Gentoo, had this issue with both the repository node (v18.14.0) and fnm's v19.7.0 (with pnpm v7.28.0).

Running pnpm add -g pnpm fixed the issue.

[mllmei]

I also had this issue

• pnpm version 7.14.2 (installed via homebrew on macOS 13, but updated over time with pnpm add -g pnpm)
• run pnpm env --global 18
• node -v returns 18
• commands ran via pnpm give engine warnings
• but things like pnpm node run the correct node version but still print the warning

Fixed the issue by running pnpm add -g pnpm

This is the only correct answer which finally worked in my project

[reikrom]

macOs Ventura 13.2.1
Using Volta to switch node versions between projects. 14 16 and 18
pnpm seems to be stuck on the node version it was installed globally at the time.
Reinstalling pnpm -g while having the desired version works as a hack.

[brxken128]

macOs Ventura 13.2.1
Using Volta to switch node versions between projects. 14 16 and 18
pnpm seems to be stuck on the node version it was installed globally at the time.
Reinstalling pnpm -g while having the desired version works as a hack.

I doubt this is the case, as I have never installed Node v14.19.2 (or a version close). That, and it seems as though a lot of people have experienced this issue randomly - it's extremely unlikely that everyone had exactly Node v14.19.2 when they installed pnpm, IMO.

[SAMDevelopment]

I had the same issue when I had pnpm installed through volta. After uninstalling it and following the regular pnpm install from the website it worked again.

[bradyab]

none of these solutions worked for me, I ended up simply installing the right node version on my machine with n <version>

[kyriacos]

I had to do a number of things to get this working. Disabled nodenv from loading and just use the pnpm global version of node. And i also had to add the specific version in my .npmrc file => use-node-version=18.15.0.

Also set in the .node-version for the project and updated the engines field. Once i did that an ran pnpm install -g pnpm it finally started working okay.

I was working in a monorepo and the problem was only for packages that did not have an .npmrc or .node-version when running a -r command like install.

Hope that helps. Thanks for all the suggestions my missing piece was the npmrc change.

pnpm v8.1.1

[theoephraim]

Also running into something like this when trying to have pnpm coexist with volta.

While having pnpm manage the node version is a noble mission, it seems that the existence of the (what should be optional) feature is somehow making things more complex instead of less... :(

More details:

Running which node results in something like /Users/theo/.volta/bin/node (which lets volta manage the version).
But adding "whichnode": "which node" to package.json scripts and running pnpm run whichnode) results in something like /Users/theo/.volta/tools/image/node/18.16.0/bin/node

While adding a specific node version in .npmrc file does tell pnpm which pnpm-managed version to use, I do not think this should be a requirement. From the behaviour above, it seems that pnpm is trying to fallback to whatever version is running locally, and while that seems reasonable, it seems to be somehow resolving the version that is running during install.

(sidenote - re-running volta install pnpm seems to at least reset it, the same way a pnpm install -g pnpm would, but keeping things in volta land)

[turbotobias]

Helper that force updates the node version by $ env 18.16.0

env() {
  echo "will set node and pnpm to v$1"
  echo "use-node-version=$1" >> .npmrc
  nvm use "$1"
  pnpm env use --global "$1"
  pnpm add -g pnpm
}

[brxken128]

Helper that force updates the node version by $ env 18.16.0

env() {
  echo "will set node and pnpm to v$1"
  echo "use-node-version=$1" >> .npmrc
  nvm use "$1"
  pnpm env use --global "$1"
  pnpm add -g pnpm
}

Not everyone uses nvm, and it's not really needed for this task AFAIK.

pnpm add -g pnpm does the trick.

[geiszla]

I'm trying to deploy to GCloud App Engine and getting the same issue. Neither of these proposed solutions would work there, would they? Has someone been able to solve this without adding engine-strict=false to .npmrc?

[FrederickEngelhardt]

Noting I had this happen. I originally installed pnpm on node 16 then jumped to node 18 with fnm I still saw a node-version=16.14.0 when running pnpm config list

[vjpr]

What does the following output: cat $(command which pnpm)

[FrederickEngelhardt]

The bin file

#!/usr/bin/env node
const [major, minor] = process.version.slice(1).split('.')
const COMPATIBILITY_PAGE = `Visit https://r.pnpm.io/comp to see the list of past pnpm versions with respective Node.js version support.`

// We don't use the semver library here because:
//  1. it is already bundled to dist/pnpm.cjs, so we would load it twice
//  2. we want this file to support potentially older Node.js versions than what semver supports
if (major < 16 || major == 16 && minor < 14) {
  console.log(`ERROR: This version of pnpm requires at least Node.js v16.14
The current version of Node.js is ${process.version}
${COMPATIBILITY_PAGE}`)
  process.exit(1)
}

global['pnpm__startedAt'] = Date.now()
require('../dist/pnpm.cjs')

// if you want to debug at your local env, you can use this
// require('../lib/pnpm')

[vjpr]

Modify that file and add which node to see where it is locating node.

pnpm usually runs from a bin stub shell script for me...I found that earlier versions hard-coded the node version.

You should also check if you use pnpm env.

This script is usually at /Users/Vaughan/Library/pnpm/pnpm. If /Users/Vaughan/Library/pnpm/node exists, it will use that.

[FrederickEngelhardt]

And script to check this real quick when upgrading

fnm uninstall 16.20.1;
fnm uninstall 18.17.0;

fnm install 16.20.1; fnm use 16.20.1; node --version; npm i -g pnpm; which pnpm; 
echo "console.log(\"NODE_VERSION\", process.version);" >> $(command which pnpm)
pnpm;

fnm install 18.17.0; fnm use 18.17.0; node --version; npm i -g pnpm; which pnpm; 
echo "console.log(\"NODE_VERSION\", process.version);" >> $(command which pnpm)
pnpm;

fnm use 16.20.1;
pnpm;

You will probably want to clean up those pnpm packages so either uninstalling node or removing pnpm from each version will remove that extract log now added to the binary file.

Outputs

/Users/<USERNAME>/Library/Caches/fnm_multishells/10299_1682566412504/bin/pnpm
NODE_VERSION v16.20.1

/Users/<USERNAME>/Library/Caches/fnm_multishells/10299_1682566412504/bin/pnpm
NODE_VERSION v18.17.0

NODE_VERSION v16.20.1

Both should output the NODE_VERSION on the top. Though for me I think I was messing around with pnpm env and I got the node-version added to my config that way.

[vjpr]

I don't see a problem with that output...

[moltar]

There's also an issue running inside GitHub Workflow. It seems like pnpm is not recognizing that the Node version already exists and updated.

We have actions/setup-node@v3 configured to set the exact version.

But then pnpm tries to update again for some reason.

[biro456]

I'm seeing this problem while using PNPM 8.8.0 while deploying to Google App Engine with Node 20 runtime.

I see no mention of the older Node version being activated by PNPM in the logs, but it still is resolving to the wrong version.
Perhaps an interesting thing is that both my workspace and a dependency have engines.node constraints (~20 and >=20 respectively), but only the dependency one is causing a failure.

As a workaround, I've disabled the engine-strict=true I have in the repo's .npmrc and the installation completed.

Logs

===> BUILDING
Timer: Builder started at 2023-09-28T05:32:33Z
=== Node.js - Runtime (google.nodejs.runtime@1.0.0) ===
Using runtime version from GOOGLE_RUNTIME_VERSION: 20.6.0
***** CACHE MISS: "nodejs"
Installing Node.js v20.6.0.
2023/09/28 05:32:33 [DEBUG] GET https://dl.google.com/runtimes/ubuntu2204/nodejs/nodejs-20.6.0.tar.gz
=== Node.js - Pnpm (google.nodejs.pnpm@0.1.0) ===
2023/09/28 05:32:37 [DEBUG] GET https://registry.npmjs.org/pnpm
***** CACHE MISS: "pnpm_engine"
Installing pnpm v8.8.0
2023/09/28 05:32:37 [DEBUG] GET https://github.com/pnpm/pnpm/releases/download/v8.8.0/pnpm-linux-x64
Setting environment variable PATH=/layers/google.nodejs.pnpm/pnpm_engine/bin:/layers/google.nodejs.runtime/node/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
--------------------------------------------------------------------------------
Running "pnpm install (CI=true NODE_ENV=development)"
Lockfile is up to date, resolution step is skipped
 ERR_PNPM_UNSUPPORTED_ENGINE  Unsupported environment (bad pnpm and/or Node.js version)

Your Node version is incompatible with "/@biro456/framework/0.1.2".

Expected version: >=20
Got: v18.5.0

This is happening because the package's manifest has an engines.node field specified.
To fix this issue, install the required Node version.
Done "pnpm install (CI=true NODE_ENV=development)" (491.23125ms)

[paro-paro]

I believe this is still an issue on pnpm 8.10.5 when installed as a standalone.

Running pnpm install with engine-strict=true set in .npmrc resolves to a "random" node version.

Note: running pnpm add -g pnpm after pnpm env use or setting the use-node-version option in .npmrc "fixes" the issue but I guess it should work without workarounds.

[lirbank]

Thanks so much @biro456 and @paro-paro! I had this exact same issue. I've uninstalled nvm, pnpm, all versions of node from all package managers and it still didn't work.

Then I commented out engine-strict=true in my .npmrc file and everything works like a charm.

I am on pnpm 8.11.0

The error I get when having engine-strict=true enabled is:

Expected version: >=18.17.0
Got: v18.5.0

The only Node version I have currently is 20.10.0, and it is installed with pnpm env use --global 20.

$ pnpm env list
  20.10.0

[CaptainOfPhB]

Modify that file and add which node to see where it is locating node.

pnpm usually runs from a bin stub shell script for me...I found that earlier versions hard-coded the node version.

You should also check if you use pnpm env.

This script is usually at /Users/Vaughan/Library/pnpm/pnpm. If /Users/Vaughan/Library/pnpm/node exists, it will use that.

The answer from @vjpr works for me. I use n to manage my node version, but I got a wrong node version and location after I installed a new node version:

$ sudo n lts
     copying : node/20.10.0
   installed : v20.10.0 to /usr/local/bin/node
      active : v18.8.0 at /Users/captainofphb/Library/pnpm/node

$ node -v
v18.8.0

$ which node
/Users/captainofphb/Library/pnpm/node

After I removed pnpm env:

$ pnpm env list
18.8.0

$ pnpm env remove --global 18.8.0
Node.js 18.8.0 was removed
/Users/captainofphb/Library/pnpm/nodejs/18.8.0

$ node -v
v20.10.0

$ which node
/usr/local/bin/node

Good!

[stolinski]

Just another data point here. I'm also having this issue. On the latest pnpm. I don't use n, nvm or any other node manager. 18.5 does not exist on my system. I have no idea where pnpm is pulling that version from.

[lewinskimaciej]

Have exact same issue:

C:\(...) (develop -> origin)
λ node -v
v20.11.0

C:\(...) (develop -> origin)
λ pnpm install
Scope: all 11 workspace projects
Lockfile is up to date, resolution step is skipped
 ERR_PNPM_UNSUPPORTED_ENGINE  Unsupported environment (bad pnpm and/or Node.js version)

Your Node version is incompatible with "/@metamask/eth-sig-util/7.0.1".

Expected version: ^16.20 || ^18.16 || >=20
Got: v18.5.0

This is happening because the package's manifest has an engines.node field specified.
To fix this issue, install the required Node version.

running on Windows if that matters, using nvm-windows but this also happened when i installed node manually. Path to node is set properly and node is usable everywhere besides pnpm.
This doesn't work even if I install node using pnpm env, it's fixated on v18.5.0 for some reason.

[woss]

i had this issue some time ago and the reason was ( in my case ) that somehow I had the $PATH variable containing the entry of different node installation rather than the nvm I was using. the solution wasn't obvious so it took a while to find out.

my take on this is that if you use pnpm to manage node version AND something else, don't. Use only one. I chose nvm, not perfectly happy with it but it does the job

[lewinskimaciej]

i had this issue some time ago and the reason was ( in my case ) that somehow I had the $PATH variable containing the entry of different node installation rather than the nvm I was using. the solution wasn't obvious so it took a while to find out.

my take on this is that if you use pnpm to manage node version AND something else, don't. Use only one. I chose nvm, not perfectly happy with it but it does the job

It's not that easy. pnpm didn't work with just pnpm env for me either(tried it before installing nvm-windows), it also lists wrong version. I tried every combination and on Windows it just doesn't recognize the version for some reason. Environment variable properly leads to the C:/Program Files/nodejs which is a symlink made by nvm, literally everything else works, just not pnpm and I'm not sure why pnpm just doesnt try to get node version by calling node -v, instead of reading something manually somewhere? For now I just disabled engine-strict in our project in .npmrc but that's hardly a solution.

[karimfromjordan]

Just another data point here. I'm also having this issue. On the latest pnpm. I don't use n, nvm or any other node manager. 18.5 does not exist on my system. I have no idea where pnpm is pulling that version from.

I'm experiencing the exact same thing.

[stolinski]

Just another data point here. I'm also having this issue. On the latest pnpm. I don't use n, nvm or any other node manager. 18.5 does not exist on my system. I have no idea where pnpm is pulling that version from.

The fix for me was uninstalling pnpm and reinstalling it via npm. I had originally installed via curl. I did not have multiple means of managing node versions and had never installed 18.5.

[magnusriga]

@zkochan Could you please explain how/where pnpm finds the node version it uses?

I have the same issue as others, i.e. that pnpm expected a certain version (the one I listed in engines), but instead "got" an entirely different (and old) version. As far as I know, I do not have that old version installed.

PS 1: I am developing in a vscode devcontainer where node was installed via an nvm script, then pnpm installed via curl. node -v and pnpm -v both print the latest versions.

PS 2: I checked out my PATH variable, and it does not contain that old outdated node version which pnpm seems to use.

PS 3: This folder does not exist on my machine: /home/$User/.local/share/pnpm/nodejs, even though pnpm is installed here: /home/$User/.local/share/pnpm/

PS 4: Adding use-node-version=21.5.0 to .npmrc partially works because pnpm then installs a second copy of node into /home/$User/.local/share/pnpm/nodejs. That seems like a bad solution, pnpm should instead use the node version that is already installed on the system. I say partially, because it creates another issue when running pnpm install:

EXDEV: cross-device link not permitted, link '/home/$User/$Project/.pnpm-store/v3/files/files/b9/86....' -> '/home/$User/.local/share/pnpm/nodejs/21.5.0_tmp_32733/share/doc/node/lldb_commands.py'

Falling back to copying packages from store

Packages are copied from the content-addressable store to the virtual store.
  Content-addressable store is at: /home/$User/$Project/.pnpm-store/v3
  Virtual store is at:             node_modules/.pnpm

I have no idea what is meant by the above. There are no cross-device links here. The project is one monorepo.

If we knew where pnpm found that old node version it uses, and directed it to look elsewhere (like via $PATH), then perhaps we could solve this quickly.

[kaechele]

Hit the same issue today. Only had time to look into possible root-cause briefly.

My guess is that the culprit is

pnpm/config/package-is-installable/src/getSystemNodeVersion.ts

Line 6 in 1a3449e

if (process['pkg'] != null) {

The release binaries seemingly bundle nodejs 18.5.0 ¹ as their runtime to bootstrap pnpm by means of the deprecated @vercel/pkg packager. The above mentioned check may be failing (might be worth trying to check for process.pkg !== undefined instead?) and the version being returned is the bundled nodejs version 18.5.0, not the system node version in your environment's PATH.

This is why the issue goes away when you install via npm -g instead of piping curl scripts to bash or using the GitHub Release provided binaries. pnpm doesn't need the bundled nodejs in that case and will always simply return the node version that was used to invoke pnpm.

Footnotes

1. As seen by running strings ~/.local/share/pnpm/pnpm | grep "18.5.0" ↩

[antony]

I believe I'm still seeing this issue too, on github actions which use node 18.19 by default, it seems.

As you can see, I run pnpm exec node -v and the version is correct as set in my .npmrc

use-node-version=20.11.0
node-version=20.11.0
engine-strict=true

when it runs pnpm install, for some reason, it's using the version of node which github actions comes with - 18.19

[antony]

In case it helps, here's a reproduction on github actions.

UPDATE: scratch that, I noticed it was using pnpm 8.3.1. Upgrading to 8.15.1 makes it work now as you can see from the build. However, I have 8.15.1 on an identical project, and that doesn't work, so now I'm baffled.

UPDATE 2: Well, after trying to figure this out for a while now, my other project build is now passing, I'm guessing that rerunning on github actions didn't cause pnpm to update, somehow, even though I can't imagine how it caches an older version since I'm enabling corepack each run.

No idea, but this is all now working for me. Hopefully it holds.

[lirbank]

I'm now on pnpm 8.15.2

It's been working for a while, but I recently added Next.js to our monorepo and the issue reappeared.

% pnpm install 
Scope: all 3 workspace projects
Lockfile is up to date, resolution step is skipped
 ERR_PNPM_UNSUPPORTED_ENGINE  Unsupported environment (bad pnpm and/or Node.js version)

Your Node version is incompatible with "/next/14.1.0(react-dom@18.2.0)(react@18.2.0)".

Expected version: >=18.17.0
Got: v18.5.0

This is happening because the package's manifest has an engines.node field specified.
To fix this issue, install the required Node version.


% which node
~/.nvm/versions/node/v20.11.0/bin/node


% node -v   
v20.11.0

[DaLukasDev]

FWIW I'm running into the same issue when using the install script from the installation section.

If PNPM is installed through the install.sh and I run pnpm config list I will get
user-agent=pnpm/8.15.3 npm/? node/v18.5.0 darwin arm64

However if I install pnpm through homebrew it will infer my node version based on what version nvm is on.
user-agent=pnpm/8.15.3 npm/? node/v20.9.0 darwin arm64

I do not have a version that is even remotly close to 18.5.0 installed on my system and I also have no idea where pnpm is pulling that from.
The issue started just now and hasn't been an issue in the past.

OS: Mac OS Sonoma (14.3.1)
Node version manager: NVM
using node version 20.9.0

tldr; Try installing it through homebrew if you're using macos.

[silasabbott]

I want to point out that many of us are getting the same exact Node version mentioned by pnpm:

Got: v18.5.0

Earlier versions of pnpm seem to be "locked" to an exact 14.x.x version if you look at comments further back.

I'm on macOS and I'm using pnpm env to manage node versions right now. A full pnpm reinstall didn't fix it for me. pnpm add -g pnpm is also not a correct fix because now pnpm recommends that you install through the convenience script.

[kaechele]

I do not have a version that is even remotly close to 18.5.0 installed on my system and I also have no idea where pnpm is pulling that from. The issue started just now and hasn't been an issue in the past.

I want to point out that many of us are getting the same exact Node version mentioned by pnpm:

I explained why that is a few comments up: #5266 (comment)

TL;DR: pnpm comes bundled with 18.5.0 when installed through the convenience script.