7 ms·

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.

• bayesian_horse 5y ago
  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...
  • ownagefool 5y ago
    That's what .lock files do though.
    • bayesian_horse 5y ago
      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.
      • epmatsw 5y ago
        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.
  • xg15 5y ago
    Then the package manager should be changed to make it more convenient.
    • bayesian_horse 5y ago
      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.
  • reasonabl_human 5y ago
    This is why I’ve warmed up to Nix, pinnacle of dependency management IMO
• laurowyn 5y ago
  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.
  • maxwell86 5y ago
    > 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).
    • cerved 5y ago
      there are other benefits with proxies but fair point
    • chmod775 5y ago
      > 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.
  • rane 5y ago
    Offline cache with Yarn 2+ protects against this and other network failures when building CI, for example.
  • chmod775 5y ago
    > 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.
  • junon 5y ago
• commandlinefan 5y ago
  > pin all dependencies You do that. Your coworkers don't. And they'll complain to your boss if you try to make them.
  • toomanydoubts 5y ago
    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.
  • TameAntelope 5y ago
    > 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.
  • gilmore606 5y ago
    > 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!
    • commandlinefan 5y ago
      But it takes longer than not doing it.
• TranquilMarmot 5y ago
  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.
  • seattle_spring 5y ago
    You should always commit a lockfile (either npm's or yarn.lock) alongside package.json
    • TranquilMarmot 5y ago
      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.
      • realityking 5y ago
        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.
  • junon 5y ago
    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.
    • Bolkan 5y ago
      Can you share it?
      • junon 5y ago
        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
• jamesfinlayson 5y ago
  Agreed - I've been bitten twice by unpinned dependencies so for a while now I've pinned everything to a specific version.
• arvinsim 5y ago
  I am still frustrated that npm install defaults to `^1.0.0` installations instead of exact `1.0.0` versions.