1. 34
  1.  

  2. 4

    Eran Hammer, if you weren’t aware, is the originator of the popular Node.js Web framework hapi. He’s pretty abrasive but he’s not wrong.

    1. 4

      What exactly is the takeaway from this rant? “Read warning messages”? “Keep your software updated”?

      I get that the author’s reason for writing was to tell off the complainers, essentially saying “it’s your fault for trusting library authors; it’s not the library authors’ fault for breaking your application.” But isn’t that logic twisted? If a library maintainer introduces a bug, obviously it’s the library maintainer’s fault. The question is whether the application developer has a Plan B for this type of situation.

      If “have a Plan B” is indeed the intended takeaway, I wish the author would say that clearly, rather than the blame-shifting approach of “you are incompetent because you trusted open source.”

      1. 4

        The takeaway is: Always pin your dependencies (possibly except dev env). We used shrinkwrap for this, now npm provides a lockfile, same for yarn.

        1. 4

          The takeaway I read into it is that if your production build process has the ability to install different versions of a million different dependencies than the ones that you previously tested on (for instance because it uses npm install and semver ranges and doesn’t lock things down), then you will at some point get screwed by that fact.

          You should have the ability to deploy the exact same code (including deps) that you test. You should have the sense to only do this. You should have tests, and they should not suck. If you do this, you won’t be the guy who said “this caused me hours of fumbling while prod was on fire”, you will be one of the people saying “my build broke, I changed the version pin, it’s OK for now”, which is better.

          If you want to be even more careful, then you don’t use ranges at all; you choose your dependencies, you maintain your own copies (so that no one else’s outages or pwnage spill onto you), and you don’t upgrade anything without having someone competent review the changes for any possible effect they have on you. Because code is so malleable, we as programmers make it a habit to replace the support columns in the basement with the newest high-tech design every time we repaint the cabinets in the kitchen… and then every now and then the house falls down in the process.

          1. 1

            Yeah, companies of any meaningful size relying on flaky redistributors like npm has always felt… odd

            1. 1

              because it uses npm install and semver ranges and doesn’t lock things down

              FYI, npm 5 and later generates a lock file automatically, so you’d have to specifically go out of your way to do this now.

            2. 2

              I don’t think that logic is twisted at all.

              There is an implied contract in open source that the maintainer(s) of a project promise constancy of some amount of functionality: that regressions are to be avoided and fixed and even that extensions and intentional changes are broadcasted and controlled. The implied contract holds because there’s an expectation that the maintainer(s) want the project to be successful as measured by the number of people who trust them enough to download and use the project.

              But that contract is just implied. For all you know, any one of your dependencies is actually has secret goals of being an art project to see how programmers respond during crisis. Or, more to the point, a con.

              The only way a bug or regression or breaking change is the “fault” of the maintainer(s) is if this implied contract holds.

              So it’s not so much whether or not you have a Plant B as much as whether you realize that you don’t have actual counterparties in the maintainer(s) who have given you a large amount of functionality you rely on. Whether you, as the responsible party for a service upon which you probably do have a contract for continued existence, support, and provision of services to your customers, are managing systemic risk appropriately.

              The obvious solution is to lock down dependencies and reduce “counterparty” risk on open source projects you use. More systemically, however, the solution is to be cognizant of assumptions like these and realize that they’re squarely upon the shoulders of the application maintainer.

              If that’s not good enough, then consider making a contract with the open source maintainers. You’ll probably need to pay them.

              1. 2

                This “implied contract” thinking is one of the strangest I’ve seen since joining BigCo. People will ask “is the project well maintained?” and don’t seem to think that the alternative is we write it from scratch – as a tech company, we write a lot from scratch and maintain all that. I’d much rather be forced to maintain a project for our use if upstream goes away then have to write from scratch and maintain!

                1. 2

                  To be fair, there are lots of cases in modern development where the alternative to taking on a dependency isn’t rewriting the whole thing from scratch; it’s being moderately inconvenienced and writing slightly more code. You use a big framework because one small corner of it makes something you’re doing easier. If it didn’t exist, you would reinvent that small corner. The biggest risk is that you reinvent it with more bugs or a worse interface.