That first recommendation of pinning exact versions of each and every dependency is borderline insane. That's exactly what lockfiles are for. Which are used by default.

▲

63stack 4 hours ago | parent | next [-]

To be honest, NPM is a complete shitshow when it comes to this, and I wish each and every single person who had a hand in developing it have their keyboards taken away, and never be allowed to touch any developer tooling ever again.

See this Stackoverflow thread:

https://stackoverflow.com/questions/45022048/why-does-npm-in...

The top answer has 3 updates to it, and links to 2 github issues, with conflicting information.

One says:

>If you run npm i against that package.json and package-lock.json, the latter will never be updated, even if the package.json would be happy with newer versions.

The other says:

>The module tree described by the package lock is reproduced. This means reproducing the structure described in the file, using the specific files referenced in "resolved" if available, falling back to normal package resolution using "version" if one isn't.

>This holds no longer true since npm 5.1.0, because now the generated module tree is a combined result of both package.json and package-lock.json. (Example: package.json specifies some package with version ^1.1.0; package-lock.json had locked it with version 1.1.4; but actually, the package is already available with version 1.1.9. In this case npm i resolves the package to 1.1.9 and overwrites the lockfile accordingly, hence ignoring the information in the lock file.)

So good luck figuring out what is true, but it seems to also depend on your version of NPM. Also, don't get me started on the presence of an entirely separate command "npm ci", which is supposed to be the one that is reproducible.

Absolute clowns.

▲

Rockslide 4 hours ago | parent [-]

Figuring out what is true for npm v5 is quite the waste of time, given that we are currently at v11. And that's what this ancient stackoverflow thread is about. npm certainly has a troubled past, otherwise we wouldn't have yarn and pnpm and whatnot. But _today_, npm install works very reasonably with lockfiles.

	▲	63stack 2 hours ago \| parent [-]
		You are right, but starting with an insane default (there is a lock file, but installing overrides and updates it), then introducing another command that does the expected behavior (npm ci), and then finally making that the default is at least confusing.

▲

bodash 5 hours ago | parent | prev [-]

The lockfile is updated _after_ any new malicious version is downloaded and installed. If we pinned the exact version, `npm install` will _not_ download and execute any new published versions.

That's why we use `npm ci` or `--frozen-lockfile` to install the exactly versions as lockfiles. But, by default, the `^` operator and just `install` command will check registry for any new releases and download them.

The primary arguments against pinning versions are missing security updates and increased maintenance overhead. But given the patterns we've seen, the attackers really _hope_ we automatically install new releases

	▲	Rockslide 5 hours ago \| parent [-]
		npm install does install the exact versions from the lockfile. Even though this misconception gets repeated in every single thread about npm here on hn. npm install will not randomly update your direct dependencies, let alone transitive dependencies.