-
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 i -g @swc/cli removed my git repository #3457
Comments
Duplicate of #2104? |
@ljharb I get this issue even though |
I can reproduce this. Simplest reproduction I've whittled it down to so far: #!/usr/bin/env bash
rm -rf prefix swc
mkdir -p prefix/lib
mkdir swc
# just a dummy file
cat >swc/package.json <<PJ
{
"name": "@swc/core",
"version": "1.2.23-alpha.1"
}
PJ
cat >swc/donotdelete <<DATA
please do not delete this file
DATA
args=(--quiet --audit=false --ignoreScripts --global)
arborist reify prefix/lib --add=file:swc "${args[@]}"
arborist reify prefix/lib "${args[@]}" --update # '--add=@swc/cli' also works
if ! [ -d swc/donotdelete ]; then
echo 'DAMAGED'
exit 1
else
echo 'PASS'
fi This seems related to a few different subtle issues combining. I can't seem to get it to reproduce in a simpler tree, so there's definitely something very interesting here relating (i think?) to a peer dep of both a top-level global package and one of its dependencies, which is not satisfied by the thing being linked, and where the peer dep itself has dependencies as well. |
Ok, I have a fix for this. It'll be in the next npm release. Thanks @nlf for pairing through it with me. |
We should never be doing this. Any time we're extracting contents, it should be into an honest to goodness directory, and not any other kind of thing. Commits to follow will make it impossible to reach this condition without some very deep hacking, but the check is here to make it easier to debug if anything like this is reported again. Related-to: npm/cli#3457
When working with the global install space, such as /usr/local/lib/node_modules, we create a "project root" at the parent of the node_modules directory, and then more or less proceed normally, with the globalStyle install strategy. The main difference, of course, is that in such a case, we should not ever place *peers* of a top-level global dependency in that same global space. This is part of the root cause of npm/cli#3457, where a peer dependency of the globally installed package was placed as a top-level globally installed package, instead of being nested under its dependent. Note that this _also_ could result in an `ERESOLVE` if multiple globally-installed packages depended upon conflicting versions of a peer dep, or worse yet, quietly replacing that peerDep in such a way that it breaks a previously-installed globally installed package. With this change, peer dependencies of a global top-level package will always be nested under their dependent, removing any chance that they might collide with anything else in the top level of the global install space. Fix: npm/cli#3457
This is fixed in npm 7.21.0 |
Is there an existing issue for this?
Current Behavior
Deletes git repository.
(Removed
.git
and tracked files)Expected Behavior
Install without error
Steps To Reproduce
resolver
branchEnvironment
Note: I installed latest version of node js because of stack trace issue on github actions.
The text was updated successfully, but these errors were encountered: