21

The first time I "npm install" package_1, I get the following error.

npm ERR! path C:\Users\john_\Documents\GitHub\why_npm_nesting_fails\package_1\node_modules\.staging\bignumber.js-55edd243

I don't use "bignumber" so assume it's a MySQL dependency. The second time I "npm install" package_1, it passes.

added 2 packages and audited 30 packages in 0.722s

It has something to do with MySQL since after deleting this dependency everything works the first time.

Here is a diagram of the dependencies:

enter image description here

The stripped-down project can be found at https://github.com/johngrabner/why_npm_nesting_fails Only 4 package.json files with 7 lines each, including { } demonstrates this problem. ie: 4 files with 1 line each that demonstrates this issue.

This problem is stopping me from cleanly placing my project into docker containers since the first "npm install" fails. A workaround of installing "package_4", then installing "package_3" and so on, works but I fear I am not understanding something that will come back and bite me.

The above issue occurs on both Windows and Docker Node:9.4.

Akhilesh Mishra
  • 5,876
  • 3
  • 16
  • 32
grabbag
  • 980
  • 1
  • 15
  • 33
  • npm -v = 6.5.0. Node -v = 8.9.4. On a windows pc. Same error in docker using "FROM node:9.4". – grabbag Dec 19 '18 at 15:51
  • Very strange observation: if i keep the package-lock.json from the previous double "npm install" then "npm install" works the first time. Also, only one "node_modules" is created in package_1 folder vs 4 node_modules being created, one in each package_n, if package-lock.json is kept. – grabbag Dec 19 '18 at 16:14
  • 1
    What version of MySQL? – Rick James Dec 22 '18 at 22:43
  • 1
    If keeping your `package-lock.json` fixes the issue, have you considered committing your `package.json`? When `package-lock.json` exists, `npm install` is supposed to refer to it before it looks at your `package.json`. https://docs.npmjs.com/cli/install#description `package-lock.json` describes the final metadata resolution that happens when `npm install` is done from scratch. – therobinkim Dec 23 '18 at 06:31
  • Myswl version 2.15.0 – grabbag Dec 24 '18 at 01:40
  • Yes saving Package-lock.json avoids the issue, but im trying to understand what the issue is. Package.json allows for up versions with ~ and ^ and package-lock.json records those choices, but first install without package fails. – grabbag Dec 24 '18 at 01:46
  • Does the problem also pop up, when you use yarn instead of npm? – BenSower Dec 27 '18 at 22:08
  • Not familiar with yarn, but looks like yarn does not allow packages to be in a local directory. In my case, package_1 is same level as my_packages, and my_packages contain dependent packages – grabbag Dec 27 '18 at 22:49
  • Spend some time with it and haven't found why. But it looks like if you go to package_2 and run npm install. Then also it behaves on the same way. I think it is to do with local packages referencing each other and being stored in nested structure instead of flat one used by npm packages. – ravish.hacker Dec 29 '18 at 00:20
  • Nesting is just like any other package, except these are private packages referenced by file spec. I found nothing described in the npm docs that packages need to be treated differently if local. – grabbag Dec 29 '18 at 14:14
  • Storing private packages in npm (paid version) solves the issue. Kind of silly to pay for npm when package is private and already stored in github. Anyhow, wish I knew how to debug this. – grabbag Jun 24 '19 at 16:31

1 Answers1

0

You should definitely always keep your package-lock.json.

Here is a good description of that file and why it's so useful: package-lock.json -- A manifestation of the manifest

The important points are:

  • Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies

and

  • Optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages

By deleting this file you will (kinda) confuse NPM.

It's easier to keep the package-lock.json file, then to deal with all the issues that will appear if you don't :)

package-lock.json

"This file is intended to be committed into source repositories"

(https://docs.npmjs.com/files/package-lock.json)

MarvinJWendt
  • 2,357
  • 1
  • 10
  • 36
  • only top-level project is supposed to have lockfiles submit, not packages. Anyhow, the real mystery is what is causing the failure rather than how to get around. Without understanding the underlying failure cause, it will likely reveal its head in the future. – grabbag Jun 24 '19 at 16:33