npm “resolved”-fields in package-lock.json change constantly with JFrog artifactory

27
votes

We have a private JFrog artifactory (name anonymised below) that npm is configured in a project root .npmrc -file:

registry=https://artifactory.jfrog.private.com:443/api/npm/npm-registry-virtual/

The resolved-field in the package-lock.json file shared via Git between developers is constantly changing between runs of "npm install" without any changes to package.json.

Some times a dl query parameter (pointing to the exactly same URL) gets added to the resolved URL:

- "resolved": "https://artifactory.jfrog.private.com:443/api/npm/npm-registry-virtual/@sailshq/lodash/-/lodash-3.10.3.tgz",
+ "resolved": "https://artifactory.jfrog.private.com:443/api/npm/npm-registry-virtual/@sailshq/lodash/-/lodash-3.10.3.tgz?dl=https://artifactory.jfrog.private.com/@sailshq/lodash/-/lodash-3.10.3.tgz",

Some times the query parameter points to npmjs.org registry:

 - "resolved": "https://artifactory.jfrog.private.com:443/api/npm/npm-registry-virtual/aproba/-/aproba-1.2.0.tgz",
 - "resolved": "https://artifactory.jfrog.private.com:443/api/npm/npm-registry-virtual/aproba/-/aproba-1.2.0.tgz?dl=https://registry.npmjs.org/aproba/-/aproba-1.2.0.tgz",

And some times the field points directly to npmjs.org repository:

- "resolved": "https://artifactory.jfrog.private.com:443/api/npm/npm-registry-virtual/acorn/-/acorn-3.3.0.tgz",
+ "resolved": "https://registry.npmjs.org/acorn/-/acorn-3.3.0.tgz",

Any of these changes may also go to the inverse direction.

This is really irritating, since it means we constantly have meaningless changes in package-lock.json, which causes merge conflicts and often prevents npm ci from executing correctly. npm cache clean --force does not seem to help. I know that npm install can resolve package-lock.json merge conflicts automatically, but that does not help with npm ci (since the whole point is to not run npm install in the CI environment). And, anyway, what is the benefit of seeing how the virtual npm registry resolves the packages internally (as I suspect is happening here)?

Is there some kind of configuration option to prevent JFrog Artifactory from making these kinds of changes to the resolved package URLs in a virtual npm registry? Or is it maybe a bug in npm?

Environment:

  • npm 6.11.3
  • JFrog Artifactory 6.10.6
3
npmartifactorypackage-lock.json
I don't see a way in which Artifactory can change the package-lock.json file. According to the npm documentation: package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. I believe this behavior is related to the npm client – Dror Bereznitsky
seem like the same question as stackoverflow.com/questions/53127140/… – Dror Bereznitsky
Maybe these settings have something to do with the issue of changing resolve fields in package-lock.json? jfrog.com/confluence/display/RTF/… jfrog.com/confluence/display/RTF/… – Ville Heikkilä
It should effect the package-lock.json as the change is done inside Artifactory before the npm client is aware of the original URL. However it is worth checking it further – Dror Bereznitsky
@VilleHeikkilä did you ever figure out how to keep the registry consistent? – samando

3 Answers

3
votes

I don't know why those alternate URLs are appearing or how to make them stop. But you can reduce (or maybe even eliminate!) the merge conflict pain for your developers by using npm-merge-driver. It was written by one of the devs who was employed on the npm cli team for years, and its sole purpose is to automate away package-lock.json merge conflicts.

0
votes

Our team has had success running npm ci first to ensure our locally pulled down and cached dependencies match the package-lock.json file.

Then, further npm installs should resolve as expected.

-1
votes

This sort of thing is normally caused by developers having slightly different versions of npm installed. Version 7 of npm just got released, so it is the perfect time to make sure the team all have exactly the same version installed.

If that doesn’t work try switching the team to yarn or pnpm.