A friend of mine has a github repo with references to how to set things up in sane and slightly more secure manner: https://github.com/jordanconway/package-manager-hardening

From that repo:

> Exact version pinning — specifying precise versions (1.0.0, ==1.0.0, =1.0.0, = 5.31.0) rather than ranges (^, ~>, >=) in package manifests. Ranges allow any version satisfying the constraint to be resolved at install time; exact pins mean only one version is ever valid.

My understanding is that pinning the dependency within the manifest isn't the mechanism that prevents the version from changing across installs -- it's the lockfile that accomplishes this.

Specifying precise versions is sufficient to ensure that the packages in your package.json are installed in the pinned versions. The problem solved by lockfiles is second, third and n-order dependencies. Just because you pinned precise versions does not mean react or vue or whatever random package you installed did as well.

That's where the lockfile comes in, it pins the dependencies of the dependencies.

The lockfile also handles the first-order dependencies, though. Pinning them in the manifest doesn't enforce this -- the lockfile does. And yes, I agree that the lockfile _also_ handles pinning dependencies-of-dependencies.

Lockfiles serve multiple purposes. For example, some include hashes so you aren't served altered packages from the package registry. I agree with you otherwise, though.

In most cases yes, but really depends on which package manager and what command, if you use npm ci, it uses the package-lock.json values, if you use npm install, it can use any levels of freedom in the package.json. So if you lock package.json you remove that degree of freedom. But sometimes you do want to be able to "recreate the lock file" since it does fix a CVE. Just with a lockdown, you'll get the legitimate patch vs an accidental malicious takeover.