[BUG] npm install followed by npm ci fails with no such file or directory (chmod failure) #2251
Assignees
Labels
Bug
thing that needs fixing
Priority 1
high priority issue
Release 7.x
work is associated with a specific npm 7 release
Milestone
Comments
tmanning
added
Bug
tmanning
changed the title
wraithgar
added
Priority 1
|
@tmanning can you try updating to the latest |
|
Issue persists from what I can tell: Results in the following: Log file contains: |
|
Hitting this as well only using GitHub Actions + npm v7 but not locally on any devs machine. Happy to provide any info to help debug or Zoom. ([email protected]). Mine isn't with aws bin but instead @cloudflare/wrangler's bin. I tried doing some digging but I'm unfamiliar with the codebase. It seems like maybe the linking of bins is ultimately handled by another library npm folks maintain bin-links. Didn't see anything immediately screwy, but then again it seems to handle lots of edge cases, and the problem might be higher in the code. FWIW |
6 tasks
|
I'm having a similar issue but in my case the dependency that causes the error is
After following these steps and even in a clean install I don’t get the error again. However this is just a workaround, I wouldn’t expect to have to install dependencies with a previous version. My impression is that having the following combo produces the issue:
|
|
Same issue here, as per aws/aws-cdk#12354. This bug prevents adoption of NPM v7 for my project. A possible work-around might be available if the lockfile version could be set in |
|
As a workaround, I deleted the In my case, the package lock file had been upgraded automatically which I think may have broken the install. Worth a shot for those stuck but can't guarantee it will work for you. Good luck. |
isaacs
added a commit
to npm/arborist
that referenced
this issue
Feb 18, 2021
We loop over the diff.leaves to find all the shrinkwraps that _must_ be unpacked ahead of time in order to complete the idealTree. However, if the idealTree already contains the children of the shrinkwrap-containing module (because it's been previously installed and saved to a lockfile), then we saw the hasShrinkwrap flag, and assumed it had already been unpacked. This tracks a Set of all nodes unpacked for the purposes of reading their shrinkwraps, and only skips _those_ modules at unpackNewModules. Different approach than #233, without adding extra items into the diff.leaves, which can have the side effect of calling mkdirp more than necessary. Close: #233 Fix: npm/cli#2251 Reviewed-by: @nlf
isaacs
added a commit
that referenced
this issue
Feb 18, 2021
* [#1875](#1875) [npm/arborist#230](npm/arborist#230) Set default advisory `severity`/`vulnerable_range` when missing from audit endpoint data ([@isaacs](https://github.com/isaacs)) * [npm/arborist#231](npm/arborist#231) skip optional deps with mismatched platform or engine ([@nlf](https://github.com/nlf)) * [#2251](#2251) Unpack shrinkwrapped deps not already unpacked ([@isaacs](https://github.com/isaacs), [@nlf](https://github.com/nlf)) * [#2714](#2714) Do not write package.json if nothing changed ([@isaacs](https://github.com/isaacs)) * [npm/rfcs#324](npm/rfcs#324) Prefer peer over prod dep, if both specified ([@isaacs](https://github.com/isaacs)) * [npm/arborist#236](npm/arborist#236) Fix additional peerOptional conflict cases ([@isaacs](https://github.com/isaacs))
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current Behavior:
When you run
npm isuccessfully followed bynpm cithe operation fails.Expected Behavior:
When you run
npm isuccessfully followed bynpm ciit should complete without errors.Steps to reproduce
package.json:
{ "name": "testnpm", "version": "0.1.0", "devDependencies": { "aws-cdk": "1.75.0" }, "dependencies": {} }npm igenerates a package-lock.jsonfollow this with
npm ciand it fails looking for
node_modules/aws-cdk/bin/cdknpm 6 does not exhibit this problem.
Environment:
The same occurs on linux
The text was updated successfully, but these errors were encountered: