43

whenever I generate a package-lock file, there is also "resolved" block that looks like this:

"resolved": "http://devel.npm.registry:4873/lodash/-/lodash-4.17.5.tgz"

What is the point of this URL? Later, if I try to install dependencies based on this package-lock, do I need to use the same npm registry? Because we use a different npm registry for local development and for production builds. Thus when I develop, I use devel.npm.registry, but the CI tool uses production.npm.registry. According to my tests, the URL doesn't matter (I tried npm@6.4.1). But it is current implementation that's gonna change soon or is the URL intentionally ignored? I have the feeling that some of the previous versions of npm actually checked the resolved URLs.

The documentation isn't much helpful in this case.

Lukáš Havrlant
  • 4,134
  • 2
  • 13
  • 18

2 Answers2

36

I found some articles on the web regarding this question. Follow the links:

npm uses a JSON as a format for the lock file. The good news is since npm@5.0.0 ignores the resolved field on package-lock.json file and basically fallback to the one defined in the .npmrc or via --registry argument using the CLI in case is exist, otherwise, it will use the defined in the resolved field.

https://medium.com/verdaccio/verdaccio-and-deterministic-lock-files-5339d82d611e

Another day, another tweet about #npm5 goodies.

npm is now agnostic about which registry you used to generate the package-lock.json.

https://twitter.com/maybekatz/status/862834964932435969

The purpose of resolved in package-lock.json is to bypass the dependency resolution step (fetching metadata) when you are missing packages. integrity is to verify that you're getting the same thing. Without the resolved field, uncached installations can break due to metadata changes, and they'll also be significantly slower because we have to do a full metadata fetch before we can actually download anything.

Note that package-lock.json does not allow different packages to be fetched from different registries. Even if you have a package lock with different packages using different resolved fields, all of the packages will always be fetched from whatever your current registry= setting is, in npmrc. resolved fields that do not match the configured registry will go through the (slower) metadata fetching I mentioned above, but will still be fetched only from the current registry.

https://github.com/npm/npm/issues/16849#issuecomment-312442508

Community
  • 1
  • 1
Lukáš Havrlant
  • 4,134
  • 2
  • 13
  • 18
  • 1
    Thanks for digging these out. I'll admit still not entirely clear why the presence of "resolved" lets you bypass the "fetching metadata" step mentioned by Kat Marchán, or even what that is! Can anyone elaborate on what exactly is going on in this mechanism? – Matt R Apr 09 '19 at 11:14
  • 1
    Thank you, this cleared up some misconceptions on my end as well - thumbs up! :) – confirmator Sep 18 '19 at 16:39
  • could you give an example in details? –  Jun 16 '20 at 13:35
  • 1
    Brilliant reference, especially the last one from official npm developers. But what on earth does "metadata fetching" mean in the quoted answer? – wlnirvana Apr 05 '21 at 07:47
0

Try to convert the package-lock.json in npm-shrinkwrap.json with npm shrinkwrap, which will keep the packages dependencies but remove the "resolved" and "integrity" attributes which causes issues on cross npm environments.

German Dario
  • 1