[BUG] Indefinite hang when installing - `Tried to end timer that doesn't exist: idealTree:#root`

[brianjenkins94]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

C:\Users\User\Desktop\foo>npx brianjenkins94/prev
Need to install the following packages:
  github:brianjenkins94/prev
Ok to proceed? (y) y
[#########.........] / idealTree:59469f58d9fd3e53: timing idealTree:#root Completed in 2416ms

Log files produced (infinite repeating output):

2022-03-29T16_49_49_474Z-debug-0.log
2022-03-29T16_49_49_749Z-debug-0.log

Expected Behavior

Package installs and runs.

Steps To Reproduce

1. npx brianjenkins94/prev
2. Indefinite hang.

Environment

• npm: v8.5.5
• Node.js: v.17.6.0
• OS Name: Windows 10 version 21H2
• npm config:

; "builtin" config from C:\Program Files\nodejs\node_modules\npm\npmrc

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

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

[fritzy]

@brianjenkins94 as a potential workaround, try specific versions for react and react-dom.
@nlf noted that this could be caused here https://github.com/npm/cli/blob/latest/workspaces/arborist/lib/arborist/build-ideal-tree.js#L1018-L1049 due to not marking the conflict.

[brianjenkins94]

Locking to v18 on react and react-dom doesn't appear to have fixed the issue:

    "react": "18.0.0",
    "react-dom": "18.0.0",

2022-03-29T18_22_33_041Z-debug-0.log
2022-03-29T18_22_33_339Z-debug-0.log

[brianjenkins94]

Locking to v17.0.2 does appear to have fixed the issue. 👍

[nickhudkins]

@nlf I actually just ran into this again, and it looks like others have as well. Using --legacy-peer-deps fixes the infinite recursion, as does specifying overrides. Looking into this further. The most interesting part for me is that I have a second package, with identical dependencies, and peer dependencies, and including a second dependency (with identical peer / dev / prod deps) appears to also result in the peer deps being resolved properly.

[slorber]

Also encountered some weird behavior in our CI while trying to upgrade the Docusaurus framework from v18 to v19

When running the npx command through a bash script, it hangs forever and I see the following logs continuously:

npm silly timing Tried to end timer that doesn't exist: idealTree:#root
npm silly placeDep ROOT @docusaurus/types@3.6.3-NEW OK for: @docusaurus/utils@3.6.3-NEW want: 3.6.3-NEW
npm silly placeDep ROOT react-dom@19.0.0 OK for: @docusaurus/types@3.6.3-NEW want: ^18.0.0 || ^19.0.0
npm silly placeDep ROOT react@19.0.0 REPLACE for: react-dom@19.0.0 want: ^19.0.0
npm silly placeDep ROOT @mdx-js/mdx@3.1.0 OK for: @docusaurus/types@3.6.3-NEW want: ^3.0.0
npm silly placeDep ROOT @types/history@4.7.11 OK for: @docusaurus/types@3.6.3-NEW want: ^4.7.11
npm silly placeDep ROOT @types/react@19.0.2 OK for: @docusaurus/types@3.6.3-NEW want: *
npm silly placeDep ROOT joi@17.13.3 OK for: @docusaurus/types@3.6.3-NEW want: ^17.9.2
npm silly placeDep ROOT react-helmet-async@1.3.0 OK for: @docusaurus/types@3.6.3-NEW want: ^1.3.0
npm silly placeDep ROOT react@18.3.1 REPLACE for: react-helmet-async@1.3.0 want: ^16.6.0 || ^17.0.0 || ^18.0.0
npm silly placeDep ROOT react-dom@18.3.1 OK for: react-helmet-async@1.3.0 want: ^16.6.0 || ^17.0.0 || ^18.0.0
npm silly placeDep ROOT react@18.3.1 OK for: react-dom@18.3.1 want: ^18.3.1
npm silly placeDep ROOT webpack-merge@5.10.0 OK for: @docusaurus/types@3.6.3-NEW want: ^5.9.0
npm silly timing Tried to end timer that doesn't exist: idealTree:#root

The npx command is ran against a Verdaccio repository for framework e2e tests:

npm_config_registry="http://localhost:4873" npx --yes --loglevel silly create-docusaurus@3.6.3-NEW test-website classic --javascript --skip-install

Surprisingly, when running the exact same command outside the bash script, it now works 🤷

It also works in the script with --legacy-peer-deps, although I'd prefer to not introduce it.

I suspect the problem is one lib doesn't support yet React 19 (recently released) in peerDependencies and it causes the problem, although the npx behavior doesn't really help to figure this out.

---

Possibly related to #5322 ?

---

Edit: can confirm it was related to a package that did not declare React 19 as peerDep: react-helmet-async@1.3.0

I forked it and added the peerDeps, and using the alias fixed my problem:

"react-helmet-async": "npm:@slorber/react-helmet-async@1.3.0",

Still think there's a npm bug because it was not so easy to figure out