Hacker News Reader

Comment by ruuda | Hacker News Reader

This is why you pin all dependencies and upgrade (and test) when it's convenient for _you_, not when the author pushes a new version.

View on HN

Pin all you want, if the repo/vendor/maintainer pulls the release then you're not getting access to your dependencies at all.

If anything, this is the reason you use pull-through proxies. Your proxy will hold the version you depend on, regardless of upstream drama. Keep your proxy backed up and you'll be able to use those dependencies until the end of time, or you finally decide to migrate to an alternative.

> if the repo/vendor/maintainer pulls the release

If your package system allows this switch to another one, like, right now.

NPM, Cargo, etc. don't allow this (they "unlist" versions, but they don't "remove" them, i.e. you can't search for them, but they are still there).

there are other benefits with proxies but fair point

> NPM, Cargo, etc. don't allow this

I'd say the likelihood is about 50% you have a NPM package in your dependencies right now that pulls some binary or whatever from a random S3 bucket during installation.

> Pin all you want, if the repo/vendor/maintainer pulls the release then you're not getting access to your dependencies at all.

And that's among the reasons people have started to commit their node_modules folders.

It has the neat side-effect of making people take a closer look at all the crap their pulling in too.

Offline cache with Yarn 2+ protects against this and other network failures when building CI, for example.

> pulls the release then you're not getting access to your dependencies at all.

NPM no longer allows this.

Which is why you pull through a private mirror that doesn’t respect delete?

The little `^` in version numbers in NPM's `package.json` file is such a bizarre choice. The fact that it by default installs all new dependencies with that means that builds on different machines at different times could result in _completely_ different artifacts.

You should always commit a lockfile (either npm's or yarn.lock) alongside package.json

This helps with CI and deploys, but on developer machines running `npm i` will install different things at different times. The amount of churn a `package-lock.json` file undergoes when all of the dependencies have a `^` is crazy.

When you have a package-lock.json file npm i will not upgrade packages. You have to do that manually.

The biggest churn in package-lock.json files is from using different npm versions. It’s worth keeping them aligned within a dev team.

I use an .npmrc in all of my repos that turns this off. It doesn't help nested dependencies but at least it reduces some of the headache.

Can you share it?

Sure, save this to `.npmrc` right next to your `package.json`. It doesn't retroactively change versions, so any existing ~ or ^ ranges need to have those characters removed. But further `npm i` invocations will save the versions without range characters.

    save-exact = true
    package-lock = false
    update-notifier = false

The only way to prevent this is to pin the actual commit. Because the meaning of the semantic version numbers is up to the package maintainers in most packaging systems. And even then you need a way to source exactly that version without relying on the original author's cooperation.

Pinning all dependencies to this extent is extremely inconvenient. More inconvenient, arguably, than to deal with this shit once in a while...

That's what .lock files do though.

Not sure if that is even enough, at least in NPM the .lock files work on semantic versions, not commits. I'm not sure if NPM enforces you to change the semantic version with each commit.

And even if all of that works, you still run head first into the issue once you inevitably upgrade the dependencies.

Yarn at least includes a hash of the tarball in the lockfile, so even if npm’s immutability fails somehow you’ll at least know.

Then the package manager should be changed to make it more convenient.

There is no way around the issue because "dependency hell" is indeed a thing.

Dependencies change. Dependencies of dependencies change. You can't not update any of your dependencies for too long or there will be other problems. Something is gotta give.

This is why I’ve warmed up to Nix, pinnacle of dependency management IMO

Agreed - I've been bitten twice by unpinned dependencies so for a while now I've pinned everything to a specific version.

> pin all dependencies

You do that. Your coworkers don't. And they'll complain to your boss if you try to make them.

That's when you make a case for why you're pinning them, allowing your coworkers to present counterarguments.

If your boss doesn't take your side, at least you can say "I told you" when things go wrong.

> Your coworkers don't.

And their PRs aren't merged until they do, because we'd have talked about it before hand and achieved consent around the idea that pinning dependencies is a practice our team will start doing, or some other specific practice that solves this problem.

> And they'll complain to your boss if you try to make them.

Really? Have I led a sheltered life? I cannot rightly apprehend the state of mind that would see pinning deps as bad. It only helps you!

But it takes longer than not doing it.

I am still frustrated that npm install defaults to `^1.0.0` installations instead of exact `1.0.0` versions.

Reply on news.ycombinator.com