[BUG] npm install will randomly hang forever and cannot be closed when this occurs

Metritutus commented 2 years ago

Is there an existing issue for this?

[X] I have searched the existing issues

This issue exists in the latest npm version

[X] I am using the latest npm

Current Behavior

When running npm install it will sometimes hang at a random point. When it does this, it is stuck forever. CTRL+C will do nothing the first time that combination is pressed when this has occurred. Pressing that key combination the second time will make the current line (the one showing the little progress bar) disappear but that's it. No further responses to that key combination are observed.

The CMD (or Powershell) window cannot be closed regardless. The process cannot be killed by Task Manager either (Access Denied, although I'm an Administrator user so I'd assume the real reason is something non-permissions related). The only way I have found to close it is to reboot the machine.

My suspicion is it's some sort of deadlock, but this is a guess and I have no idea how to further investigate this. I've tried using Process Explorer to check for handles to files in the project directory from other processes but there are none. There are handles held by the Node process npm is using, and one for the CMD window hosting it, but that's it.

Even running with log-level silly yields no useful information. When it freezes there are no warnings or errors, it just sits on the line it was on. This is some log output from one of the times when it got stuck (I should again emphasise that the point where it gets stuck seems to be random, so the last line shown here isn't always the one it freezes on):

npm timing auditReport:init Completed in 49242ms
npm timing reify:audit Completed in 55729ms
npm timing reifyNode:node_modules/selenium-webdriver Completed in 54728ms
npm timing reifyNode:node_modules/regenerate-unicode-properties Completed in 55637ms
npm timing reifyNode:node_modules/ajv-formats/node_modules/ajv Completed in 56497ms
npm timing reifyNode:node_modules/@angular-devkit/schematics/node_modules/ajv Completed in 56472ms
[##################] \ reify:ajv: timing reifyNode:node_modules/@angular-devkit/schematics/node_modules/ajv Completed in 564

The only thing that I can think of right now is that Bit Defender (the only other application running) is interfering somehow, however it's the one application I can't turn off.

I've seen this issue occur on different projects, on different network and internet connections, and on different machines. Does anyone have any advice on how to investigate this, or at the very least a way to kill the process when it hangs like this without having to reboot the machine? Being forced to reboot when this issue occurs is perhaps the most frustrating thing in all of this.

Expected Behavior

npm install should either succeed or show an error. If it gets stuck it should either time-out or be closable by the user.

Steps To Reproduce

Clear down the node_modules folder (ie with something like rmdir /q /s)
Run. npm install
Watch and wait.
If it succeeds, repeat the above steps until the freeze is observed.

Environment

npm: 8.1.3
Node: v16.13.0
OS: Windows 10 Version 21H1 (OS Build 19043.1288)
platform: Lenovo ThinkPad

npm config:


; "builtin" config from C:\Users\<REDACTED>\AppData\Roaming\npm\node_modules\npm\npmrc

prefix = "C:\Users\\AppData\Roaming\npm"

; "user" config from C:\Users\.npmrc

//pkgs.dev.azure.com//_packaging//npm/registry/:_authToken = (protected)

; node bin location = C:\Program Files\nodejs\node.exe ; cwd = C:\Users\ ; HOME = C:\Users\ ; Run npm config ls -l to show all defaults.

JanesH64 commented 5 months ago

Same issue here in WSL2 and Ubuntu. Even when upgrading to node 22.2.0.

PieterjanDeClippel commented 5 months ago

For me it seems that this works for me

Remove node_modules
Remove package-lock.json
Remove %userprofile%/.npmrc
Run npm cache clean --force as administrator
Reboot computer
Run npm i

bertutron commented 5 months ago

i removed package-lock.json and it worked

DominoTree commented 4 months ago

All this time I had assumed this was an issue on my end - imagine my surprise to find out about an unresolved three-year-old ticket about it 🤣

Next time it happens I'm gonna see if I can attach strace or similar and see if it's actually churning on anything

DominoTree commented 4 months ago

I've found a way to reliably trigger this on my system.

Delete node_modules project folder
Run npm install (this works as expected)
Delete ~/.npm
Run npm update (this "deadlocks")

Here's the package.json and package-lock.json I've been using:

package.json package-lock.json

I've captured the system calls via strace including the main thread and all children and attached the output. At a glance, it seems like after a while, the child threads stop doing much of anything, and the main thread will sit in a loop making DNS requests over and over, not responding to a SIGKILL or SIGINT or otherwise (unless you wait about a minute and it finally responds to the signal it was sent before.)

Some sort of deadlock or lock contention is my first guess, but I haven't really dug in much beyond capturing some data.

Command:

strace -ff -s 128 -r -o ~/npm_hang npm update

Versions:

12:29:29 nprice@terrestrial ~ node --version
v22.3.0
12:29:40 nprice@terrestrial ~ npm --version
10.8.1

Full output:

hang.tar.gz

DominoTree commented 4 months ago

I haven't bothered to break TLS yet, but as far as network traffic is concerned, at the moment things hang, there's a DNS request for the PTR of the host's IP, and data stops flowing immediately (although the TCP connections are held open)

It gets the response (a second later which is normal behavior because it has to recurse all the way to the root servers to get a canonical NXDOMAIN back which won't be subsequently cached on the recursive resolvers), and immediately queries the remote host's IP. It gets that response, and immediately queries the local host's IP, ad infinitum.

The TCP keepalives continue along with the DNS requests, and npm only starts to respond again when one of the connections is finally reset and everything gets torn down.

Unfortunately, the pcap is too large to attach, but this screenshot from Wireshark shows the moment this behavior starts

Screenshot 2024-06-13 124926

mirek commented 4 months ago

All this time I had assumed this was an issue on my end - imagine my surprise to find out about an unresolved three-year-old ticket about it 🤣

Next time it happens I'm gonna see if I can attach strace or similar and see if it's actually churning on anything

Yes, we've got nice, thriving niche community support group around this single issue here. We share our daily stories how different spooky actions at a distance may or may not have an impact on this problem.

lppedd commented 3 months ago

Incredible that this is still an issue. That's the last straw for me. Going to switch to pnpm.

yejimeiming commented 3 months ago

I had been using node@16.15.0 and everything worked fine until yesterday 2024/07/16 when the same problem started to occur.

Try to use npm i --no-audit or add audit=false to .npmrc

DominoTree commented 3 months ago

Unfortunately I haven't had a chance to come back to this, but my "gut feeling" is that this is a deadlock caused by an issue with DNS timeouts in the c-ares library implementation - which only manifests under specific circumstances (that I have been able to reliably reproduce, but not narrow down yet)

Specifically I think it's some sort of behavior around resolving PTR records, but this is all just mostly a guess at the moment

WarboxLiam commented 3 months ago

Quote reply

This is the only thing that's worked for me so far. Besides what I'm about to do, which is move to pnpm.

smcfizz commented 3 months ago

I encountered this issue after messing around with my locally installed versions of node, I must have gotten things mucked up somehow.

I was able to resolve this issue (and some others) by uninstalling all versions of node from my machine with nvm uninstall <version> and then reinstalling the current LTS version (NOT the latest version) of node (v20.15.1, which includes npm version 10.7.0) via nvm install --lts and things started working properly again.

Hope this helps.

Praveen-98cs commented 3 months ago

I am also facing the same issue. it's stuck here and not going any forward. I am using the latest version. what i did was using npm init -y but this issue needs to be solved.

npm init
This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

See `npm help init` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.json file.

Press ^C at any time to quit.
package name: (sample-node-application)

DominoTree commented 3 months ago

It's now reliably spinning forever for me unless I pass --no-audit - however it does exit if I hit ^C which wasn't the case before

A different hang that isn't a deadlock?

TrystanCars commented 3 months ago

I am getting the same issues on our CI system. npm hangs forever.

AMSHL commented 3 months ago

Found out that getting this problem in my CI pipeline yestarday. The--no-audit doesn't help. Strange thing, that when run it on the same node version locally it works like a charm.

jeff-traba commented 3 months ago

Same, started happening yesterday

adityagoel-hexgit commented 3 months ago

Same. Happening since yesterday.

jesben commented 3 months ago

Same here, started yesterday. It gives me huge problems!

Temporary workaround, set env variable in pipeline PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true

Run installation manually, which hangs forever, after message "downloaded to ..." do "ctrl c" (Hmm are "process.exit(0);" missing?) node /home/site/wwwroot/dist/apps/api/node_modules/puppeteer/install.js

Another problem same headless=true operation with Puppeteer and Chrome (same versions than before) in production is now 3 times slower than before! It's driving me crazy, I don't understand why...

puppeteer": "20.9.0"
HeadlessChrome/115.0.5790.98

env:

PUPPETEER_DISABLE_HEADLESS_WARNING="true"
PUPPETEER_CACHE_DIR=/home/site/wwwroot/dist/apps/api/node_modules/.cache/puppeteer

abine-praveen commented 3 months ago

The actual problem is with the puppeteer version: The problem is that puppeteer version < 22 is deprecated and this the culprit which is making the "npm i" getting stuck on CI.

The actual fix is to upgrade puppeteer to the version >= 22 this will solve the issue

adityagoel-hexgit commented 3 months ago

@abine-praveen . Thanks it worked.

jeff-traba commented 3 months ago

Sorry, I should have checked in as well. Upgrading puppeteer to >=22.0 was also our solution. Havent explored why 21 causes the issue though. theres an issue open https://github.com/puppeteer/puppeteer/issues/12833

DominoTree commented 3 months ago

FWIW I have a feeling the CI/CD issues being reported here are probably unrelated to the initial report - I haven't had time to dig into it any further, but the behavior sounds different from the total deadlock initially reported

TrystanCars commented 3 months ago

FWIW I have a feeling the CI/CD issues being reported here are probably unrelated to the initial report - I haven't had time to dig into it any further, but the behavior sounds different from the total deadlock initially reported

Upgrading Puppeteer to @latest completely resolved our CI issues (CircleCI).

Abdelazizmuhmd commented 3 months ago

I solved the hanging problem in windows by disabling "Controlled Folder Access"

hyphen81 commented 3 months ago

Just started running into timeout issues when running npm ci && npm run build, which seem to be related to puppeteer. Prior to a few days ago, was working without issue. Wondering if others that have recently commented on this thread are also experiencing a regression from previously working deployments? I'm currently running 21.3.8, and hesitant to upgrade.

abine-praveen commented 3 months ago

Just started running into timeout issues when running npm ci && npm run build, which seem to be related to puppeteer. Prior to a few days ago, was working without issue. Wondering if others that have recently commented on this thread are also experiencing a regression from previously working deployments? I'm currently running 21.3.8, and hesitant to upgrade.

yes, we had our CI pipe-line which was working completely fine and it suddenly started failing and i spent 1 day to figure iut the problem and found this "The actual problem is with the puppeteer version: The problem is that puppeteer version < 22 is deprecated and this the culprit which is making the "npm i" getting stuck on CI."

abine-praveen commented 3 months ago

Sorry, I should have checked in as well. Upgrading puppeteer to >=22.0 was also our solution. Havent explored why 21 causes the issue though. theres an issue open puppeteer/puppeteer#12833

Puppeteer has changed the chrome download end-point, that's the reason it is failaing

sc0ttdav3y commented 3 months ago

I'll add my solution in case it helps others. I'm building Puppeteer in Docker via AWS Codepipeline on an earlier AWS Linux OS.

Like others, my CI pipeline failed around the end of July 2024. I can't upgrade puppeteer > v21 to this due to underlying dependencies (the OS can't get above Node 16.20, so Puppeteer 21 is the latest I can use).

What ended up working for me was this line in my Dockerfile:

RUN echo "audit=false" > /root/.npmrc

that fixed these commands which were stalling during the chrome download step:

RUN npm i -g puppeteer@$PUPPETEER_VERSION
RUN puppeteer browsers install chrome@$CHROME_VERSION

igortas commented 2 months ago

npm randomly hangs on concat-map on latest pre-release WSL2 with cleaned node_modules and package-lock... --lts or latest node version

DominoTree commented 2 months ago

npm randomly hangs on concat-map on latest pre-release WSL2 with cleaned node_modules and package-lock... --lts or latest node version

This is the specific issue I am able to reproduce which (to me) seems to involve DNS lookup timeouts from within the WSL environment

igortas commented 2 months ago

npm randomly hangs on concat-map on latest pre-release WSL2 with cleaned node_modules and package-lock... --lts or latest node version

This is the specific issue I am able to reproduce which (to me) seems to involve DNS lookup timeouts from within the WSL environment

npm is following the same pattern installing the pckgs... removing lastly added pckgs and re-adding in different order helped me prevent the issue....

the-xentropy commented 2 months ago

In my experience, this behavior ocurrs when execute npm install or npm uninstall in a windows console that not is maximized (cmd, powershell, nodejs command prompt, etc.). I don't know why ocurrs this error, but if we can maximize terminals before execute these commands we can avoid the freezing behavior.

I hope this can help you guys.

Best regards from El Salvador.

You absolute legend, I would never in a million years have thought to root-cause it down to the window size. Thanks! It's a ridiculous bug, bug at least it has an insanely easy workaround.

FWIW, the bug is present in 10.8.2 (the latest public release as of writing). Unclear what it's caused by, but changing terminals made absolutely no difference to me. Powershell, cmd, and even changing the terminal handler program, made no difference.

Edit: I still need to add --verbose for it to work, but I went from no ability to install anything to being able to install anything very strangely, so ultimately still an improvement.

keaedwar commented 2 months ago

I've been using npm 10.7.0 without a problem for a long time and yesterday, I removed node_modules and ran "npm i" and it hung. spent time yesterday looking for solutions without success. (The maximized window, cmd, PowerShell, Windows Terminal didn't work for me either). This morning I still couldn't get it to work. I just upgraded to npm 10.8.2 and it worked. Other members on my team had npm v10.7.0 and are running without a problem. There must be some external dependency that's causing a problem because I see people running into the hang problem while others with the same installed versions (node & npm) not having any problem.

Windows 10 Enterprise 22H2 Build 19045.4780 node v18.20.3 npm 10.8.2

Just adding a little more detail. We have about 10 web applications where we have no hangs on previous versions of npm. Another developer was using npm 10.7.0 on his own web app and was working fine, but as soon as he went to another web app, it hung. He upgraded to npm 10.8.2 and the web app where it hung now works.

the-xentropy commented 2 months ago

I've been using npm 10.7.0 without a problem for a long time and yesterday, I removed node_modules and ran "npm i" and it hung. spent time yesterday looking for solutions without success. (The maximized window, cmd, PowerShell, Windows Terminal didn't work for me either). This morning I still couldn't get it to work. I just upgraded to npm 10.8.2 and it worked. Other members on my team had npm v10.7.0 and are running without a problem. There must be some external dependency that's causing a problem because I see people running into the hang problem while others with the same installed versions (node & npm) not having any problem.

Windows 10 Enterprise 22H2 Build 19045.4780 node v18.20.3 npm 10.8.2

Just adding a little more detail. We have about 10 web applications where we have no hangs on previous versions of npm. Another developer was using npm 10.7.0 on his own web app and was working fine, but as soon as he went to another web app, it hung. He upgraded to npm 10.8.2 and the web app where it hung now works.

Try the combination of maximizing it, --verbose, and re-running it a few times (so caches populate). I know it sounds like one of those ridiculous unhelpful tips you see on Quora or Microsoft support forums and such, but it basically is dark magic to solve this.

the-xentropy commented 2 months ago

I'm writing down all the things I changed/set to solve my issue. I'm unaware of which K of N solved it, but hopefully the list is useful to people trying to chase down this super annoying issue since there's practically zero logs to root-cause it from:

I run npm install with --verbose (note: this solved it sporadically on its own)
I maximize the terminal (as in, hit the maximize button) (note: this solved it most of the time when combined with --verbose )
I set registry = "http://registry.npmjs.org/" in npm config
I set loglevel = "info" in npm config
I set strict-ssl = false in npm config
I set progress = false in npm config
I run the most recent npm (10.8.2, as of writing)

After doing the above, it now works every time provided --verbose is set.

More specifically:

npm config set strict-ssl false
npm config set progress false
npm config set loglevel info
npm config set registry http://registry.npmjs.org/ --global

Note that I forgot to set the strict-ssl, loglevel, etc, globally, but in the interest of communicating explicitly what I did and not some variant I'm including my errors as-is. I don't see why you couldn't use --global for all of them, but then I also don't understand the root cause of the issue so I'm leaning towards being overly specific.

Then install things with (in a maximized terminal):

npm install <package> --verbose

As an aside, I can also confirm that I am on Windows. Windows 11 Pro Version 10.0.22631 Build 22631, to be specific.

igortas commented 2 months ago

npm just love to hang on concat-map...

npm http fetch GET 200 https://registry.npmjs.org/onetime 25ms (cache hit)
npm http fetch GET 200 https://registry.npmjs.org/siginfo 15ms (cache hit)
npm http fetch GET 200 https://registry.npmjs.org/stackback 13ms (cache hit)
npm http fetch GET 200 https://registry.npmjs.org/get-func-name 2ms (cache hit)
npm http fetch GET 200 https://registry.npmjs.org/shebang-command 3ms (cache hit)
npm http fetch GET 200 https://registry.npmjs.org/mimic-fn 2ms (cache hit)
npm http fetch GET 200 https://registry.npmjs.org/shebang-regex 3ms (cache hit)
npm http fetch GET 200 https://registry.npmjs.org/vscode-jsonrpc 3ms (cache hit)
npm http fetch GET 200 https://registry.npmjs.org/vscode-languageserver-types 5ms (cache hit)
npm http fetch GET 200 https://registry.npmjs.org/crc32-stream 2ms (cache hit)
npm http fetch GET 200 https://registry.npmjs.org/crc-32 1ms (cache hit)
npm http fetch GET 200 https://registry.npmjs.org/argparse 3ms (cache hit)
npm http fetch GET 200 https://registry.npmjs.org/concat-map 2ms (cache hit)

pfeileon commented 1 month ago

npm randomly hangs on concat-map on latest pre-release WSL2 with cleaned node_modules and package-lock... --lts or latest node version

I suspect that this is actually just coincidence. When I added the packages which depend on concat-map to my package.json, npm got stuck after the package pend (concat-map's and its depending packages' caches have already been updated by then).

Btw, this happens when I remove package-lock.json or execute ng update @angular/cli.

pfeileon commented 1 month ago

npm randomly hangs on concat-map on latest pre-release WSL2 with cleaned node_modules and package-lock... --lts or latest node version

I suspect that this is actually just coincidence. When I added the packages which depend on concat-map to my package.json, npm got stuck after the package pend (concat-map's and its depending packages' caches have already been updated by then).

Btw, this happens when I remove package-lock.json or execute ng update @angular/cli.

So what I found out is that the process is actually completed successfully in the end, it simply takes forever (i.e. 20+ minutes).

nickamckenna commented 1 month ago

I have this problem at the Windows command prompt, but using a bash prompt works fine!

igortas commented 1 month ago

@nickamckenna Here's how it works fine in bash in WSL2, once again is stucked, famous concat-map!!

npm http fetch GET 200 https://registry.npmjs.org/loupe 108ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/tinyspy 134ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/loupe 154ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/deep-eql 225ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/cac 245ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/stackback 317ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/assertion-error 332ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/check-error 406ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/siginfo 819ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/get-func-name 107ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/vscode-jsonrpc 99ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/vscode-languageserver-types 103ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/crc32-stream 96ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/crc-32 100ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/argparse 102ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/concat-map 61ms (cache revalidated)

joshuawwright commented 1 month ago

@igortas I have the exact same issue. It can be replicated on WSL 2 Ubuntu 20.04, by running npx create-nx-workspace.

StorytellerCZ commented 1 month ago

Got hit with this problem today on Ubuntu 24.04.1 LTS. Gets stuck on fetching (event the loader icon stops).

I've removed node_modules and package.lock I have very similar project as well that is a companion to the one where I do the install and there npm runs without problem (though I have to use npm i --force as I'm testing React 19 there). The only notable change I can think of was update of storybook, which the other project doesn't have. Even when reverting to the previous version and running with --force I get to the same place as in the screenshot and get stuck. The node_modules folder is created, but many of the folders remain empty.

UPDATE: I was able to get un-stuck by running npm i on another computer and then copying over the newly created lock file.

lxchurbakov commented 1 month ago

Removing package-lock is considered a bad practice. What can be done for those who can't remove it? Our app is quite old and won't resolve all the subdependencies properly so we can't remove lock. Cleaning cache or removing node_modules doesn't help - npm still hangs on reify or reifyNode for too long. However running it with --package-lock-only seems to solve the issue.

Tofandel commented 4 weeks ago

I'm having this issue on npm ^10, and it always happen (it's not random) even if I remove the lockfile or node_modules, it happens on multiple of my projects, it hangs after having downloaded everything

It doesn't hang on npm ^9

Here is the package.json that always fails for me

{
  "name": "web",
  "type": "module",
  "version": "0.1.0",
  "private": true,
  "scripts": {
  },
  "devDependencies": {
    "@nuxt/image": "^1.7.0",
  }
}

I tried npm cache clear --force and still the same issue

I'll try to pinpoint the exact version in which this started happening

Edit: it doesn't happen on 10.3.0 and happens on 10.4.0

This is the most likely culprit I found https://github.com/npm/cli/pull/7124/files

Tofandel commented 4 weeks ago

Interesting, now I do manage to get it to finish sometimes by keeping only very fews deps and when it usually hangs I now get this log npm http fetch POST 200 https://registry.npmjs.org/-/npm/v1/security/advisories/bulk 31783ms

30seconds to fetch security advisories.

On 10.3.0 it happens in 2seconds (and somehow the log shows it as negative time)

npm http fetch POST 200 https://registry.npmjs.org/-/npm/v1/security/advisories/bulk -2283ms

The more deps I have the longer the hangs take exponentially

If I run with --no-audit it still hangs for the same exact amount of time but doesn't log it. I'm guessing maybe promise-call-limit is making the promises wait for much longer than they should. (I checked and my promise limit is set at 15)

I'll also point out that in npm ^9 instead of hanging I had an error message about node.target cannot be destructured because it's null

This all points to this piece of code in arborist https://github.com/npm/cli/blob/6ca609e20b68fb2e5ef8177db116b84a339461fd/workspaces/arborist/lib/arborist/rebuild.js#L289-L301

The arborist node that seems to hang

reify:fsevents: timing reifyNode:node_modules/@parcel/watcher-android-arm64 Completed in 26978ms

ArboristNode {
    name: 'fsevents',
    version: '2.3.3',
    location: 'node_modules/fsevents',
    path: '***/node_modules/fsevents',
    resolved: 'https://registry.npmjs.org/fsevents/-/fsevents-2.3.3.tgz',
    dev: true,
    optional: true,
    edgesIn: Set(3) {
      { node_modules/chokidar optional fsevents@~2.3.2 },
      { node_modules/rollup optional fsevents@~2.3.2 },
      { node_modules/vite optional fsevents@~2.3.3 }
    }
  }

I'm not sure how to debug further than this, I am also on WSL2 which seems to be the common denominator. I'm guessing file system events are not working properly or take way longer than they should and npm is waiting for a fs-event (why I don't know though)

This bug has hindered me so much that I switched to pnpm for the time being

jsbmg commented 1 week ago

I experienced this issue as well, on a fresh git clone of a NextJS project. I was able to install with pnpm. When I ran the project, I received this error:

FATAL ERROR: v8::Object::GetCreationContextChecked No creation context available

Which, based on this issue, is solved by switching Node versions to 22.5.1 (I was on 22.5.0).

After that, I decided to try npm install again (after deleting node_modules and the newly created pnpm-lock.yaml). This time, it worked.

So, in short, I might have had random luck, or possibly switching Node versions from 22.5.0 -> 22.5.1 was a workaround.

VibingCreator commented 1 week ago

npm http fetch GET 200 https://registry.npmjs.org/@types%2fd3-array 737ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/@types%2fd3-time 1272ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/@types%2fd3-ease 1312ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/d3-time-format 52ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/d3-path 79ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/d3-format 82ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/internmap 84ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/d3-color 104ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/@types%2fd3-color 122ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/@types%2fd3-path 1224ms (cache revalidated)

I have similar issues with NPM recently. It's stuck...

¯_(ツ)_/¯ Switching to pnpm!

Tofandel commented 1 week ago

You can also downgrade npm npm i -g npm@10.3.0 instead of switching to pnpm which has is own set of issues as well, the issue starts after 10.4.0

KrashLeviathan commented 6 days ago

I used a combination of the above comments by @jsbmg and @Tofandel along with nvm to get things to work. Not sure if the versions of node/npm I used are the absolute latest working versions, but I'll take them for now until the bug is resolved in a forthcoming patch. 👀

nvm install 22.5
npm install -g npm@10.3.0
node -v    # output: v22.5.1
npm  -v    # output: 10.3.0

npm / cli