-
Notifications
You must be signed in to change notification settings - Fork 3k
Conversation
Thank you so much! Will this make it for 5.5.x? |
@zkat That uniq is running over a map that maps to the pkg objects, which have a shared identity. |
Ah! I missed where the parens were for that. 👍👍👍 To this |
As a rule this only happens if it doesn't exist, though it could also be Windows holding a file open. Either way it shouldn't break the install.
Merged as 0bea588 into |
Please see my comment under #19042: This PR is a great relief already, but still does not solve the issue caused by concurrent removal of nested directories which I am addressing in #19042 as well. It only makes it less frequently by removing the duplicate rollbacks and less annoying by converting the errors to warnings. But they can still happen, and the warning text "this is probably harmless" that now will appear every once in a while for Windows users may still be irritating. |
@redukted Could you run a simulation of this PR similar to https://github.com/reduckted/repro-npm-17671 to see the issue still manifests with this PR? |
Edit: The initial tests I ran were invalid (I hadn't set it up correctly). Here are the correct results... Since this now ignores the error and produces a warning, I've changed the repro to consider an execution of npm that outputs "EPERM" to be a warning instead of a success. As I did over in #19042 (comment), I let it do 200 iterations. The results are:
An example of one of the warnings is:
|
@reduckted Thanks so much :) So according to your tests:
(Please note that these tests are specifically related to concern #17671) |
@Karasuni Sorry, I messed up the first test run 😨. I've updated my comment with the correct test results. It now doesn't fail, but instead it produces a warning about failing to rollback quite a lot. |
@reduckted OK, no problem! I've also updated my comment. From those numbers it looks like the PR triggers the race condition at the same rate but catches it instead of handling it. |
@SiggeSeb Actually there are two reasons that cause these errors: 1) duplicate rollbacks, and 2) nested rollbacks. Both PRs solve problem 1) in a similar way. #19054 does not solve 2) but alleviates the pain by turning the error into a warning. #19042 solves 2) by simply skipping nested rollbacks assuming that a rollback of a parent package also rolls back the subpackages anyway. I guess this latter assumption might not always be true if packages implement some special custom rollback methods, and that might be the reason why it was not merged. But I'm not sure. As I explained in #19042, the default rollback method uses the For the time being, #19054 is an acceptable solution. And in the meantime if anybody wants to work on npm/fs-vacuum#8 that would be highly appreciated. |
it is annoying to see how long windows users are struggling with this kind of npm install issue(s) for months and people dont want to accept merge request(s) because it is not the best solution right of the shelf. |
Optional dependencies pre [email protected] caused troubles. Specifically, fs-events which is MacOSX only. npm/npm#19054 fixed this. But the npm version installed by default for various node modules needs to be upgraded for this to work. We add a pre `npm install` step to do the needful for both travis-ci & appveyor. YMMV
This PR does not fix EPERM error in a correct way. Please consider #19042 as a better fix. npm v5.6.0 still throws same EPERM error: ... npm ERR! A complete log of this run can be found in: babichea@USPLMWN116020 MINGW64 /d/npm-projects/fsm/FlashSetManager.FrontEnd (tokens-login-logout) $ npm -v |
Makes full package-locks even the package.json has optional deps that are currently uninstallable. Also stops deleting optionals from package-locks when we can't install them.