-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] npm ERR! Cannot destructure property 'name' of 'node' as it is null. #2548
Comments
If a git dependency has conflicting peerDependencies, dependencies with engines fields that don't match the current environment, and so on, it isn't much help to crash the installation for these issues. The user installing the git dependency is likely not in a position to fix them, but from npm and Arborist's points of view, it is the 'main' project that has a problem (since the install is being run as a separate process). This commit passes '--force' to the npm child process that installs dependencies for git packages before running their 'prepare' script, to ignore all such issues (or reduce them to warnings). Related to: npm/cli#2548
If the virtualRoot node has a sourceReference, and that sourceReference node would get its devDep edges loaded, then the virtualRoot node should as well. This caused a very useless ERESOLVE error, which could not be properly forced away, when installing in a project that had conflicting peer deps in its dev tree. Related to: npm/cli#2548
If the virtualRoot node has a sourceReference, and that sourceReference node would get its devDep edges loaded, then the virtualRoot node should as well. This caused a very useless ERESOLVE error, which could not be properly forced away, when installing in a project that had conflicting peer deps in its dev tree. Related to: npm/cli#2548
There are two issues here. As it happens,
The general situation is like this:
Then the package depends on To solve this, we'd have to unwind the stack all the way back. So, we can't get [email protected], is there any other 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 The solution, of course, is to just specify that you want 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 Second issue, this is happening in a project that isn't even When those two land, this should work as expected. |
If the virtualRoot node has a sourceReference, and that sourceReference node would get its devDep edges loaded, then the virtualRoot node should as well. This caused a very useless ERESOLVE error, which could not be properly forced away, when installing in a project that had conflicting peer deps in its dev tree. Related to: npm/cli#2548
If the virtualRoot node has a sourceReference, and that sourceReference node would get its devDep edges loaded, then the virtualRoot node should as well. This caused a very useless ERESOLVE error, which could not be properly forced away, when installing in a project that had conflicting peer deps in its dev tree. Related to: npm/cli#2548
If the virtualRoot node has a sourceReference, and that sourceReference node would get its devDep edges loaded, then the virtualRoot node should as well. This caused a very useless ERESOLVE error, which could not be properly forced away, when installing in a project that had conflicting peer deps in its dev tree. Related to: npm/cli#2548 PR-URL: #214 Credit: @isaacs Close: #214 Reviewed-by: @nlf
If a git dependency has conflicting peerDependencies, dependencies with engines fields that don't match the current environment, and so on, it isn't much help to crash the installation for these issues. The user installing the git dependency is likely not in a position to fix them, but from npm and Arborist's points of view, it is the 'main' project that has a problem (since the install is being run as a separate process). This commit passes '--force' to the npm child process that installs dependencies for git packages before running their 'prepare' script, to ignore all such issues (or reduce them to warnings). Related to: npm/cli#2548 PR-URL: #63 Credit: @isaacs Close: #63 Reviewed-by: @nlf
@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 |
I can confirm, error above doesn't show up anymore in 7.5.1 👍 |
Seeing this pop up for me on [email protected].
|
Downgrading to 7.5.1 and still getting this error.
|
I'll open a new issue. Thanks |
I am experiencing this on npm v7.6.1 as well: I ran
|
I still experience this in npm 7.21.0 Here's the log file
|
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:
Yields:
Environment:
The text was updated successfully, but these errors were encountered: