npm on Windows fails with module not found for Node.js 22.0.0

[prabhu]

Version

22

Platform

Windows

Subsystem

No response

What steps will reproduce the bug?

npm install command is enough to reproduce the issue.

Example workflow: https://github.com/CycloneDX/cdxgen/actions/runs/8823813113/job/24236408405#step:10:18

How often does it reproduce? Is there a required condition?

Always

What is the expected behavior? Why is that the expected behavior?

No response

What do you see instead?

node:internal/modules/cjs/loader:1205
  throw err;
  ^

Error: Cannot find module 'C:\npm\prefix\node_modules\npm\bin\npm-cli.js'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1202:15)
    at Module._load (node:internal/modules/cjs/loader:1027:27)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:187:14)
    at node:internal/main/run_main_module:28:49 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

Additional information

No response

[Thanaen]

For your information, I have the same problem on my Windows machine, so it's not just a problem with Github actions

PS C:\Users\me> node --version
v22.0.0
PS C:\Users\me> npm --version
node:internal/modules/cjs/loader:1205
  throw err;
  ^

Error: Cannot find module 'C:\Users\me\AppData\Roaming\npm\node_modules\npm\bin\npm-cli.js'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1202:15)
    at Module._load (node:internal/modules/cjs/loader:1027:27)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:187:14)
    at node:internal/main/run_main_module:28:49 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

[danieljameswilliams]

I am also experiencing this.

[targos]

@Thanaen

• How did you install/update Node.js?
• Does C:\Users\me\AppData\Roaming\npm\node_modules\npm\bin\npm-cli.js exist on your system?

I'm currently not able to reproduce on my Windows machine. I tried:

• With Volta version manager (my usual setup)
• With the offitial .msi installer (in a Windows Sandbox)

C:\Users\WDAGUtilityAccount>node -v
v22.0.0

C:\Users\WDAGUtilityAccount>npm -v
10.5.1

[Thanaen]

@targos
I updated Node via the node-v22.0.0-x64 installer, downloaded directly from the Node website.

When I saw that it didn't work, I uninstalled Node, then did a clean install, with the same installer file. (after cleaning up all the cache files etc)

I then tried activating corepack and installing npm via corepack (corepack enable then corepack prepare npm@latest --activate)

After checking, it seems that the C:\Users\me\AppData\Roaming\npm folder doesn't exist 😅

Also, I've changed the npm_config_cache environment variable to point to my Dev Drive, so maybe that's a factor?
PS: I've tried removing my environment variable, but it doesn't fix the problem

[Thanaen]

@targos I've just tried installation via Volta, and npm works correctly.
Maybe a problem with the MSI installer and Windows 11?

[targos]

I don't know how to reproduce on my Windows system but it seems indeed to be a general issue on GitHub actions (which download the binary from https://nodejs.org/dist/v22.0.0/node-v22.0.0-win-x64.7z): https://github.com/nodejs/citgm/actions/runs/8831148407/job/24245743480?pr=1056

[alvicode]

have the same issue

[targos]

The main difference I see between v20/v21 and v22 is the presence of npm.ps1 and npx.ps1 in the distribution.
This is from #52009

/cc @nodejs/npm @lukekarrys

[targos]

Also /cc @StefanStojanovic.

I'm trying to find a simple reproduction but I hit another problem. Here are the steps I took:

• Download v22 from https://nodejs.org/download/release/v22.0.0/ (I used the -arm64.zip one)
• Extract it and cd into it.
• Run:

PowerShell 7.4.2
PS C:\Users\mzasso\Documents\node-v22.0.0-win-arm64\node-v22.0.0-win-arm64> .\node.exe -v
v22.0.0
PS C:\Users\mzasso\Documents\node-v22.0.0-win-arm64\node-v22.0.0-win-arm64> .\npm.cmd -v
10.5.1
PS C:\Users\mzasso\Documents\node-v22.0.0-win-arm64\node-v22.0.0-win-arm64> .\npm.ps1 -v
node.exe not found.

Suggestion [3,General]: The command "node.exe" was not found, but does exist in the current location.
PowerShell does not load commands from the current location by default (see ''Get-Help about_Command_Precedence'').

If you trust this command, run the following command instead:
PS C:\Users\mzasso\Documents\node-v22.0.0-win-arm64\node-v22.0.0-win-arm64>

[targos]

Then I installed a global node.exe with Volta and hit another (still different, but similar) issue:

PS C:\Users\mzasso\Documents\node-v22.0.0-win-arm64\node-v22.0.0-win-arm64> .\npm.ps1 -v
node:internal/modules/cjs/loader:1205
  throw err;
  ^

Error: Cannot find module 'C:\Program Files\Volta\node_modules\npm\bin\npm-prefix.js'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1202:15)
    at Module._load (node:internal/modules/cjs/loader:1027:27)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:187:14)
    at node:internal/main/run_main_module:28:49 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

Node.js v22.0.0
Could not determine Node.js install directory

Maybe the problem is that the npm.ps1 script tries to determine where npm is installed based on where the global node.exe is installed? This seems wrong.

[wraithgar]

This appears to be a problem w/ the base node installation in windows itself.

A related issue is npm/cli#6971

It seems that in some installations npm does not end up where it belongs? Or is missing directories?

[wraithgar]

Maybe the problem is that the npm.ps1 script tries to determine where npm is installed based on where the global node.exe is installed?

No, it tries to ask windows where node.exe is

$nodebin = $(Get-Command $nodeexe -ErrorAction SilentlyContinue -ErrorVariable F).Source

It then looks to the parent folder of the node executable and starts looking for npm there

$nodedir = $(New-Object -ComObject Scripting.FileSystemObject).GetFile("$nodebin").ParentFolder.Path

That's why this is happening

Suggestion [3,General]: The command "node.exe" was not found, but does exist in the current location.
PowerShell does not load commands from the current location by default (see ''Get-Help about_Command_Precedence'')

There is no node executable that is in a valid path. Windows is refusing to consider the one in the cwd as valid when npm asks for it because of command precedence.

[wraithgar]

npm.cmd looks for node using %~dp0\node.exe. Is it getting a different answer for this than Get-Command?

[targos]

npm.cmd looks for node using %~dp0\node.exe. Is it getting a different answer for this than Get-Command?

Yes. %~dp0 is the directory that contains npm.cmd

[wraithgar]

npm has to make an assumption that npm and node are in the same place, and based on that can go find itself. npm.cmd and corepack do this by evaluating %~dp0\node.exe. npm.ps1 does this by calling Get-Command node.exe.

Is there another node.exe that is in the path? How do these strings materially differ, shouldn't they be the same?

It looks like that difference is the root cause here. We'll keep this issue open to track the work instead of making duplicates.

While we're on the subject however, it appears that this npm.ps1 file is not properly digitally signed in the node installation. cf npm/cli#7280.

[wraithgar]

This may represent a larger issue that has to date gone unnoticed. What npm is trying to make sure of is that node and npm are both reached by the same method. If there is some other node installation that is called when a person runs node that differs than the one npm shipped with that could cause problems. There is no guarantee that other version of node even works with this version of npm.

If Get-Command node.exe is not returning the same node.exe that is alongside the file that runs when npm.ps1 is called, that is an issue. It seems like it's an issue w/ the installer in that it's not putting the version of node that was installed properly in the user's PATH.

[wraithgar]

In the short term, we'll update the .ps1 script to use %dp0, @lukekarrys is working on this.

[lukekarrys]

npm.cmd looks for node using %~dp0\node.exe. Is it getting a different answer for this than Get-Command?

Yes. %~dp0 is the directory that contains npm.cmd

I think this is a mistake in the ps1 scripts that npm ships with then. They should be using %~dp0 instead of Get-Command. I'll make a PR to npm fixing this in npm.ps1 and npx.ps1.

It appears that this npm.ps1 file is not properly digitally signed in the node installation. cf npm/cli#7280.

I would be curious if anyone knows how to fix the issue with digitally signing the ps1 scripts. I don't think it's directly related to this issue, but v22 is the first time these scripts are included in the Node installer. I'm not sure if this is something that should be fixed on the npm or node side.

[richardlau]

%~dp0 is a .cmd/batch file thing. Powershell equivalents (depending on the version being targetted): https://stackoverflow.com/a/36417541

[richardlau]

As for signing, Node.js signs assets it produces (the node.exe file, and msi installer). The logic for that is in vcbuild.bat. However, I'd be a little wary of using Node.js' signing certificate to sign something originating from outside of Node.js.

[StoneCypher]

This is the expected error if the image just didn't set the path

[lukekarrys]

For visibility, I wanted to surface another bug found in the new npm Powershell scripts that shipped with v22, since folks watching this issue might hit this one as well.

The full details are here (npm/cli#7375 (comment)) but the gist is argument parsing is different between batch/cmd files and powershell, so attempting to call a run script like npm run echo -- arg1 --arg2 will not pass the --arg2 along due to the leading dashes.

To get the same behavior in Powershell you need to run npm run echo --% arg1 --arg2. Edit: this is not fully equivalent. See the linked issue fore more details.

So far I have not been able to fix this in npm's Powershell shim to get parity with the batch file. If this is not possible, then npm might chose to remove the PS1 shims and send a PR to remove them from the Node installer as well.

[cclauss]

UPDATE: https://github.com/actions/node-versions/releases/tag/22.1.0-8926142033

---

https://github.com/npm/cli/releases/tag/v10.7.0 in GitHub Actions:

      - uses: actions/setup-node@v4
        with:
          node-version: 22.x

      - if: runner.os == 'Windows'
        shell: bash  # Not pwsh 
        run: |
          npm install -g npm  # >= https://github.com/npm/cli/releases/tag/v10.7.0

This currently upgrades npm v10.5.1 to v10.7.0.

[prabhu]

I think node requires a "python -m pip" style solution, if resolving npm path or passing run args is difficult.

[cclauss]

python -m pip

python3 -m venv .venv should be used instead to isolate projects and not install dependencies from all projects into the system Python. If you are in an activated virtualenv then python -m is not required.

• https://docs.python.org/3/library/venv.html

In GitHub Actions setup-python creates and activates a virtualenv.

[andreyquerino]

$ npm -v

node:internal/modules/cjs/loader:1205
  throw err;
  ^

Error: Cannot find module 'C:\Users\<username>\AppData\Roaming\npm\node_modules\npm\bin\npm-cli.js'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1202:15)
    at Module._load (node:internal/modules/cjs/loader:1027:27)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:187:14)
    at node:internal/main/run_main_module:28:49 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

Node.js v22.0.0

You have to copy C:\Program Files\nodejs\node_modules\npm to %AppData%\Roaming\npm\node_modules temporarily.

I think this issue only occurs on:

• Fresh installation of Node v22
• Upgraded to Node v22 but never installed npm globally (npm i -g npm) before

The new npm script seems to only check global installation by default and will not use the version bundled in the Node installation directory.

Thank you very much, it worked perfectly here!

[elite-mob]

Getting the exactly same issue when I try to run the yarn commands.

[cclauss]

https://github.com/actions/node-versions/releases/tag/22.1.0-8926142033 fixes things in GitHub Actions for me.

      - uses: actions/setup-node@v4
        with:
          node-version: 22.1

[jameslund]

This issue is easy to reproduce if one creates a windows docker container and happens to install nodejs via chocolatey choco install -g nodejs. If one opens a command prompt, npm works fine. Using powershell however, attempting to run npm fails with the error from the OP. The solution for my container is running from command prompt only npm install -g npm as pointed out by @cclauss .

[hongphuc1912]

INSTALL THE LATEST VERSION v22.1.0 NODEJS , THAT WOULD FIX THE BUG GUYS ! I TRIED AND GOOD TO USE !

[lukekarrys]

This issue has been fixed in the latest npm 10 and Node 22 releases.

I'm going to close this but open a new issue for something we found from debugging this:

The Windows installer places the npm shim files in a location that takes precedence over the global npm packages directory. So subsequent npm installs via npm install npm --global will install a new npm version, but won't update the shims placed by the Windows installer.

This is only an issue when there exists a bug in the shim files like in this issue. In that scenario installing a new version of npm won't fix the shim files, which feels like an oversight because those files live in the npm repository.

[mrgrain]

This issue has resurfaced in Node.js 20.13.0 which was released earlier today.
See #52884