[BUG] npm ERR! Cannot destructure property 'name' of 'node' as it is null.

[dmnsgn]

Opening a new issue as requested by @isaacs #1832 (comment)

Current Behavior:

Installing a dependency from a GitHub URL fails.

Expected Behavior:

Dependency is installed without error.

Steps To Reproduce:

npm init -y
npm i -D git://github.com/GoogleChromeLabs/critters.git

Yields:

npm ERR! code 1
npm ERR! git dep preparation failed
npm ERR! command /usr/local/bin/node /usr/local/lib/node_modules/npm/bin/npm-cli.js install --cache=/Users/my-name/.npm/_cacache --prefer-offline=false --prefer-online=false --offline=false --no-progress --no-save --no-audit
npm ERR! npm ERR! code ERESOLVE
npm ERR! npm ERR! Cannot destructure property 'name' of 'node' as it is null.

Environment:

• OS: MacOS 10.15.6
• Node: v15.5.1
• npm: 7.4.0

[isaacs]

There are two issues here.

As it happens, critters has a legit peer dependency issue that we can't unravel (or rather, won't, as it would require explosively expensive traversals, in the general case -- there is a solution, but finding it is too hard).

The general situation is like this:

a@1 -> b@>=1
a@2 -> b@>=2
a@3 -> b@>=3
b@1 -> c@>=1
b@2 -> c@>=2
c@1 -> d@>=1
c@2 -> d@>=2
c@3 -> d@>=3

Then the package depends on {a: "1.x", d: "2.x"}.
npm resolves a@1.x to a@1.0.0, and looks for b@>=1.
This resolves to b@3.0.0, and now it looks for c@>=3
This resolves to c@3.0.0, and now it looks for d@>=3, and whoops there's no version available that meets the d@>=3 requirement without conflicting with the root's dependency on d@2.x!

To solve this, we'd have to unwind the stack all the way back. So, we can't get c@3.0.0, is there any other c@>=3 that doesn't have the same problem? No, so we can't use b@3.0.0, is there any other b@>=1 that doesn't depend on a known-bad version of c? Yes, let's try b@2.0.0, then c@2.0.0, then d@2.0.0, and we have our answer.

However...

There may be 10 different packages in the stack, across 10 different majors, each with 100 different patch versions to check, and this becomes O(n!) in many cases, for a very large n. Even pubgrub gives up eventually.

The solution, of course, is to just specify that you want b@2 and c@2 in your package.json, problem solved.

It would be easy enough for a human brain familiar with the code to see what deps need to be specified to give npm enough to go on. However, how would you know what's happening with such a useless ERESOLVE error?

First issue is that it wasn't tracking the dev dependencies properly when creating the tentative/virtual tree to resolve against. That's fixed by npm/arborist#214, so we get a proper ERESOLVE with a "current" value.

Second issue, this is happening in a project that isn't even critters! What are you supposed to do about it? Probably better to just ignore ERESOLVE errors that happen among transitive devDependencies at git preparation time, so that's fixed in npm/pacote#63

When those two land, this should work as expected.

[darcyclarke]

@dmnsgn Closing: As I just tried this out & it seems to be working as of npm v7.5.1 - you can grab the latest via npm i -g npm@7.