NPM lockfiles/shrinkwrap get random "dl" parameter tacked on to the "resolved" URL
Asked Answered
I

1

35

Our company uses an Artifactory repository for storing internally-published packages and as a proxy for the NPM registry. Sometimes the resolved field in lockfiles/shrinkwrap files is as expected, containing URLs for our internal repository, but occasionally they show up as something like this (line break added for clarity):

https://our.repository.com/artifactory/api/npm/some-repo/lodash/-/lodash-3.10.1.tgz
  ?dl=https://registry.npmjs.org/lodash/-/lodash-3.10.1.tgz

Then, from pull request to pull requests, these dl parameters constantly oscillate to being present or removed depending on which developer does an npm install, leading to a lot of pull request & commit noise.

I'm guessing it's Artifactory that's adding this dl param, since I fail to see it in a code search in the npm code base.

Why does this happen? Can we disable this behavior? And is it safe to strip this parameter as a postshrinkwrap script workaround?

Ingate answered 2/11, 2018 at 23:57 Comment(9)
Hey Jacob! did you progress on that by any chance?Pectase
Nope, it's still a mystery. Will try a bounty.Ingate
@ciekawy: What's your setup? Maybe there's some common elements with our org that will help us narrow it down?Ingate
We're just suffering from this as a dev team so I am not sure about the artifactory setup. Raised that on our company slack - will follow up upon any new info.Pectase
I am having this same problem with my company's artifactory as well.Landry
I am also using Artifactory and we are having the same issue. Does anyone have found what causes the dl params to be appended depending on the developer? Is there a solution even partial?Selfesteem
I also have this problem with artifactory. Version 6.3.4.Sisterly
Also hitting this, and starting a bounty for more visibility. Any leads will be helpful.Mistiemistime
Also experiencing this issue - just commenting to get notifications in case anybody discovers a root cause.Pyroelectric
B
2

I think the root of your problem is likely caching.

NPM caches packages that have been downloaded, so they don't have to be downloaded again, and they can even be re-installed offline if necessary. It also caches the resolved value for later use. If a package of the same version has already been resolved and downloaded, it doesn't need to go and fetch it again and get the updated download/resolved URL.

You can manually clear this cache with the following command.

npm cache clean --force

Alternately, it could be that difference in how different versions of NPM calculate the resolved field are to blame (following the Location header or not). However I think caching is more-likely to blame.

Beaulieu answered 24/12, 2019 at 18:37 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.