Missing dependencies after running
npm install a second time
I'm opening this issue because:
What's going wrong?
When there is an existing lockfile,
The initial invocation of
When I delete
How can the CLI team reproduce the problem?
This seems to be a minimal test-case that shows how
# scaffold a minimal project $ mkdir npm5-test $ cd npm5-test $ npm init -y # install/save my first/only dependency $ npm i foundry-kue-scheduler npm WARN deprecated firstname.lastname@example.org: possible critical bug, see https://github.com/mike-marcacci/node-redlock/issues/31 npm notice created a lockfile as package-lock.json. You should commit this file. npm WARN email@example.com No description npm WARN firstname.lastname@example.org No repository field. added 203 packages in 11.601s # npm installed my packages and creates a lockfile $ ls -lh total 88 drwxr-xr-x 194 andrew staff 6.4K May 31 15:09 node_modules -rw-r--r-- 1 andrew staff 38K May 31 15:09 package-lock.json -rw-r--r-- 1 andrew staff 286B May 31 15:09 package.json # one of my transitive dependencies is present $ ls -lh node_modules/kue/package.json -rw-r--r-- 1 andrew staff 2.0K May 31 15:09 node_modules/kue/package.json # At this point, everything is OK. # NPM has installed the set of packages that I expected. # I can run `npm install` again, and it correctly reports that there's nothing to do. # now, let's remove node_modules and reinstall (as though I'm installing # packages for the first time in a repo that has package-lock.json checked-in, # and node_modules is listed in .gitignore ) $ rm -rf node_modules/ $ npm i npm WARN email@example.com No description npm WARN firstname.lastname@example.org No repository field. added 192 packages in 4.73s # note that fewer packages were installed, and npm MODIFIED the extant lockfile $ ls -lh total 88 drwxr-xr-x 185 andrew staff 6.1K May 31 15:11 node_modules -rw-r--r-- 1 andrew staff 36K May 31 15:11 package-lock.json -rw-r--r-- 1 andrew staff 286B May 31 15:11 package.json # also, my transitive dependency is gone. $ ls node_modules/kue/package.json ls: node_modules/kue/package.json: No such file or directory # subsequent invocations of npm install make things even worse $ npm i npm WARN email@example.com No description npm WARN firstname.lastname@example.org No repository field. removed 190 packages in 3.026s # ahhhhhh! $ ls -lh total 16 drwxr-xr-x 5 andrew staff 170B May 31 15:15 node_modules -rw-r--r-- 1 andrew staff 503B May 31 15:15 package-lock.json -rw-r--r-- 1 andrew staff 286B May 31 15:15 package.json
Here's a gist that shows the package structure, as well as the changes to
The text was updated successfully, but these errors were encountered:
Some quick discussion:
The broken transitive dependency (
The fact that the "bare"
I would not be surprised if
This seems like a bug, but there doesn't seem to be much documentation about the contracts that NPM makes with regards to lockfiles, or how they're meant to be used in a typical workflow. For all I know, this could be an expected behavior. More documentation would be helpful.
My $0.02 is that the "bare"
Seeing these same results. We committed our package-lock.json after a brand new
By weird, I'm seeing an issue where the repository URL ends up in the "version" field of package-lock.json.
I am seeing something very similar when updating a single package. For example, once everything is working fine, I can do this:
note that I just deleted one package that I directly depend on, and then running
What is weirder is that if I do
If I do something silly like go into a working directory that's all properly installed and do
In all cases, this is only repaired by deleting both package-lock.json and node_modules and doing a fresh
I was going to file my own bug, but I think this one covers my experience. I've managed to create a minimal experiment and demo repo that reproduces this behavior; the README has all the details:
Hopefully it's helpful here. The upshot: the problem appears related to
I think I was able to work around it by manually installing the missing dependencies until there were none left and letting
❯ npm test module.js:487 throw err; ^ Error: Cannot find module 'pretty-error' at Function.Module._resolveFilename (module.js:485:15) ❯ npm install pretty-error npm WARN email@example.com No repository field. + firstname.lastname@example.org added 21 packages, removed 1 package and updated 14 packages in 3.072s ❯ npm run test module.js:487 throw err; ^ Error: Cannot find module 'wrap-ansi' at Function.Module._resolveFilename (module.js:485:15) ❯ npm install wrap-ansi npm WARN email@example.com No repository field. + firstname.lastname@example.org added 1 package, removed 1 package and updated 14 packages in 2.519s ❯ npm test IT WORKS!
Now to confirm it actually helped anything:
❯ rm node_modules ❯ npm test module.js:487 throw err; ^ Error: Cannot find module 'yargs' at Function.Module._resolveFilename (module.js:485:15) ❯ npm install added 380 packages in 55.731s ❯ npm test IT WORKS!
I'm going to do some more testing, however I wanted to report my strange findings here in case it helps anyone. Hope we can get this resolved soon!
I can confirm the comment by @Glavin001. We handled it by having our developers that removed node_modules remove
I upgraded to npm5 while using Expo (for react native, it installs about 700 packages within node_modules without adding them to package.json)
I did npm install for the first time to add one package and it pruned the entire node_modules directory, and I had to downgrade to npm4.x , create a new Expo project, and copy paste my src folder and configs.
Is it a feature that npm5 prunes by default on each install or was it an attempt to make it "better than yarn"? Because that didn't work at all, I went back to yarn after all.
The behavior of the mbland/npm-v5-package-lock-bug-demo scenarios still holds under 5.0.3. (Note: I haven't been pushing
Though I've a lot of detail in the README of that repo already, I've a few more observations and thoughts I'll share here.
Problems arise when only one artifact is present
First problem: missing
I can also confirm this - using private repo aka
Is it possible that during typing keyphrase for ssh, the time used to do it can change anything?
This issue happened to me when I requested from the Development server a bundle without the platform and dev flags.
I was requesting the bundle like
Once I changed it to
I've just seen this on a Dependabot pull request and dug into it. I think I have a fix, but my knowledge of the npm codebase / JS isn't good enough to implement it and (particularly) write tests for it.
First up, here are some reproduction steps:
Next up, I think I've isolated the problem in npm:
Finally here is a PR that I'm pretty sure fixes this
I'd love help from a maintainer to get it tested and over the line.
Well, I've found a reason of this "remove all of them" behavior of npm.
It's all about
In the process of installation of ANY package locally, npm will auto-scan versions of every package recorded in the
I will just remind, that version
So, I think it can be confusing for a lot of people. When, for example they know, that Angular 5 doesn't has "cataclysmic" changes in compare to Angular 4.
And if your
... and all your
It was like that couple days ago with npm v5.6.0 ... and yesterday they released version 6.0.0, and it still works in this not very smart order.
So, be careful, folks!