Hacker News Reader

Comment by Epskampie | Hacker News Reader

Awesome writeup, I agree with mostly everything. A few small tips:

* Use `npm ci` instead of `npm i --no-save`. This gives you the exact packages from the lockfile, which is more reliable.

* You might like systemd .service files instead of `mon`. It's available by default on ubuntu LTS, and you're down a dependency that way. The .service files can be really simple: https://techoverflow.net/2019/03/11/simple-online-systemd-se...

View on HN

Thanks for your comment!

- I don't use lockfiles - instead I use very very few dependencies, and I always target a specific version of each of them. I know this is not the same as a shrinkwrap, but I'm crazy enough to feel that package-lock.json adds visual bloat to my repo.

- I am biased towards mon because it's probably less susceptible to changes over time than Ubuntu itself, and because it can be installed with a single command. But systemd definitely is a good option too if you're using Ubuntu!

The main problem with your approach is that you have full control over your dependencies but no control over their dependencies, unless you're inspecting every single package in your dependency graph to make sure that every one of them targets specific versions in its package.json. Realistically, using package-lock.json and npm ci is the only way to ensure that everyone on your team and your deployments are all working off of the same node_modules folder.

There's one problem with `npm ci`: it deletes the `node_modules` directory, thereby thwarting attempts at caching it between builds. As a workaround, we use `npm install` followed by `git diff --quiet package-lock.json`, which will abort the CI process if npm installing changed the lock file (i.e. if someone forgot to commit changes to it after adding a package).

Lockfiles protect you from someone who would publish a malware that replaces an existing version (lockfiles have hashes alongside the versions)

I believe that npm no longer allows for republishing existing versions. Wouldn't this restriction remove this vulnerability altogether?

It won't protect against a newer version of an established library introducing malicious behaviour.

This is correct, the few dependencies you would use would need to also target very specific versions to achieve the same.

Lock files are used to lock dependency versions all the way down your dependency tree, not just your immediate dependencies.

Unfortunately this seems to be the case; lockfiles would be unnecessary only if all your dependencies (and their dependencies, recursively all the way down) reference explicit versions, the risk being that a new malicious version would be published. I'll research if there's a workaround.

Thanks everyone for pointing out this issue.

In my opinion a lock file really is the "work around", I don't see a huge issue in using them since it's given for free by npm and yarn with no additional overhead.

You can specify exact versions, but your deps might wildcard with "~" or "^" or they might specify a range of versions. Thus, a new dep of a dep might be installed the next time you update.

I wonder whether one of the npm alternatives has a "--sane" mode that would always pick the oldest possible dep...

Why the oldest possible?

Thread hypothesis is that we want to avoid breakage due to automatic dependency updates. So, don't update dependencies automatically. Now sure, if you tell the tool to update a particular dep, it will force second- and higher-order deps to update to compatible versions. It will always use the oldest compatible version, so nothing will get broken in surprising fashion. This seems strange to people who've used mostly npm and node, but tools for other languages have this policy.

I see. I've never heard of that before, thanks for sharing!

Reply on news.ycombinator.com