npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

Pin dependency version


I see some vulnerable nested deps. How can I pin the versions before the packages which deps are vulnerable release an update?

npm audit does not show anything, but Github shows a huge banner with the security vulnerability.

The previous issue I had opened didn’t answer my question and is closed now, super annoying.

Thank you

It is a bit tricky modifying nested dependencies.

Is this project in a public repo so we can take a look?

Best is to pin it with shrinkwrap or any other lockfile. The resolved fields are a bit tricky.

Yes it is, we have the vulnerability issue reported in by Github.

Can one do that with package-lock?

package-lock.json gives reproducible dependencies for developers who are running npm install in a git clone, for example. shrinkwrap gives reproducible dependencies for npm install of cli applications.

Alright now I get it. Thanks for clarifying this.

Is there any plan to make npm install work the way shrinkwrap works? This would make things easier because that’s exactly what everyone expects from it and besides, in other package managers like cargo, there is a special command to update the deps, i.e cargo update.

Back to the original question. If we were to use a shrinkwrap instead of package-lock to make builds fully reproducible, how would one pin the dependency (i.e edit the shrinkwrap manually or is there a package.json field for that?) or is it simply not possible at this point?

A quick update on the shrinkwrap, I’ve just used the npm shrinkwrap and ran npm i, the npm-shrinkwrap.json received an update. This is against how lock files work.

     "tar": {
-      "version": "4.4.8",
-      "resolved": "",
-      "integrity": "sha512-LzHF64s5chPQQS0IYBn9IN5h3i98c12bo4NCO7e0sGM2llXQ3p2FGC5sdENN4cTW48O915Sh+x+EXx7XW96xYQ==",
+      "version": "4.4.9",
+      "resolved": "",
+      "integrity": "sha512-xisFa7Q2i3HOgfn+nmnWLGHD6Tm23hxjkx6wwGmgxkJFr6wxwXnJOdJYcZjL453PSdF0+bemO03+flAzkIdLBQ==",
       "optional": true,
       "requires": {
         "chownr": "^1.1.1",
         "fs-minipass": "^1.2.5",
-        "minipass": "^2.3.4",
-        "minizlib": "^1.1.1",
+        "minipass": "^2.3.5",
+        "minizlib": "^1.2.1",
         "mkdirp": "^0.5.0",
         "safe-buffer": "^5.1.2",
-        "yallist": "^3.0.2"
+        "yallist": "^3.0.3"

(I am sure what you mean with the extra questions, npm install does update the package-lock.json file, and there is an npm update command?)

Thanks for package link. I can’t see any alerts directly on GitHub. That might be restricted to collaborators for security reasons.

As for updating nested dependencies in your lock file, one simple low-tech approach might be editing the package-lock of the nested project to change its dependency, and then running npm install from your outer package to update the nested dependencies and your lock file.

My extra question was in regard of npm install rewriting the package-lock.json and even npm-shrinkwrap.json because of a loose version requirement for one of the nested deps (i.e ^x.y.z). I had asked if there was a plan to address this and treat all dependencies listed in package-lock as frozen. i.e if a developer wants to update anything, they have to run npm update {dependency-name}

Regarding the CVE, it’s possible that the security alerts are only displayed to collaborators, in any case, Github points to The suggestion is to update axios from 0.18 to 0.19. Since we don’t use axios directly and it’s a part of nested dep, there is really nothing we can do to cover this security hole. The good thing it’s a dev dependency issue, so it 's not that much of a deal.

There is npm ci for this, see