5 ms·

Everyone crying about this on the Internet would do better to just take it as an easy lesson: pin your dependency versions for projects running in production.

Everyone crying about this on the Internet would do better to just take it as an easy lesson: pin your dependency versions for projects running in production. This was an honest oversight, and even somewhat inevitable with so many expected supported ways to import/export between cjs mjs amd umd etc. It will happen again. And when it happens the next time, if it ruins your life again, take issue with yourself for not pinning your dependency versions, rather that package maintainers trying to make it all happen.

tgv 7y ago
> pin your dependency versions And then to see "npm detected 97393 problems" or whatever the message exactly is.
- acdha 7y ago
  That’s good: it’s easy to update and it means you do it in a controlled manner rather than the next time something deploys.
- montroser 7y ago
  You don't need to pin them forevermore -- just when you don't want everything to break unexpectedly :). When you want to upgrade your dependencies, then go ahead and do that, on your own schedule, with time and space to fix whatever issues come up, update your tests, QA, etc.
mikewhy 7y ago
> pin your dependency versions for projects running in production Works for existing apps, but people using create-react-app and angular CLI can't even start a new project.
- staticassertion 7y ago
  I don't know much about those projects, but why did this break them? Are they not pinning versions?
  - yandie 7y ago
    Because they are starting a new project from scratch and would have nothing to pin their dependencies against?
    - staticassertion 7y ago
      Maybe I'm misunderstanding how those projects work. From what I recall, they generate a project, including the package.json. So I'm not sure why they couldn't just generate the package.json with pinned versions? I don't write much JS, and have only used create-react-app just a few times, so feel free to explain why this isn't possible.
      - mikewhy 7y ago
        package.json only lists top-level dependencies. package-lock.json tracks all dependencies, and dependencies of dependencies. is-promise is one of those dependencies of a dependency, which you don't have much control over.
        rsanek 7y ago
        How could a dependency-of-dependency change version if one of the direct dependencies doesn't change version? I guess, if the direct dependency isn't pinning that version? Another case of, everyone should be pinning dependencies.
        mikewhy 7y ago
        Exactly, node's conventions are to allow a range of versions (semver compatible). True, if all dependencies were pinned, this wouldn't come up as often. That also means that there would be a lot more updating when security issues are found.
        staticassertion 7y ago
        How would a top level dependency change versions if it bumped a transitive dependency? Is that a thing in js-land?
- montroser 7y ago
  Nah, create-react-app and others could easily pin dependencies of libraries they install in your new project to known-good versions. Without doing that bit of diligence, this type of issue should be 100% expected.
  - mikewhy 7y ago
    By doing that they would avoid this issue, for sure. They would also introduce security issues by using old versions. And this would do nothing for the fact that `npm install eslint && ./node_modules/.bin/eslint` was also failing.
    - montroser 7y ago
      It's not like pinning means you can /never/ update. You just get to do it on your own schedule. You can even automate updating to some degree -- running your tests against the latest everything and then locking in to those versions of all goes well.
      - mikewhy 7y ago
        Again, this only works for project skeletons, and not for any other package that happened to have a transient dependency on `is-promise` (which is a lot more than project skeletons).
    - tirpen 7y ago
      Pinning dependencies might introduce security issues. Not pinning dependencies is a security issue.
  - oefrha 7y ago
    Then you can’t upgrade anything unless create-react-app releases a new version (or you eject), which, in addition to the obvious release cadence problem, might introduce other compatibility problems.
2OEH8eoCRo0 7y ago
I'm a novice in this area but if your project relies on a bunch of external node packages why wouldn't you download them all and host them locally or add them to version control?
- winrid 7y ago
  You'd use a proxy, yes.
- IAmEveryone 7y ago
  Adding them to your own version control is a nightmare: Your own work will drown in all the changes in your dependencies. The repository will quickly grow to gigabytes, and any operation that would usually take seconds will take minutes. It's also just not needed. Simply specifying an exact version ("=2.5.2") will avoid this problem. The code for a version specified in this manner does not change.
  - montroser 7y ago
    Yes, putting your dependencies in version control alongside your project is no fun. Commit history is muddied, but also if your production boxes are running on a different platform or architecture than where you and your team develop, that can make a big mess too. That said, with a big enough team and risk-averse organisation, it can be a brilliant idea to put your dependencies in /separate/ version control and have your build process interact that way. In that scenario, even if your dependencies vanish from the Internet (as happened with left-pad), you are still sitting pretty. You can also see exactly what changed when, in hunting for causes of regressions etc.
  - 2OEH8eoCRo0 7y ago
    To me an even bigger nightmare is your entire project or product depending on some external resource you don't control.
- jdlshore 7y ago
  Checking them into your repo is called “vendoring” and it’s one way of solving the problem, yes. Personally, it’s my favorite approach. But it does have some challenges, as other commenters point out.
btilly 7y ago
And everyone who depends on projects that pin their dependency versions gets to be victims of security exploits long after they are fixed. Dependency management is not as simple as you seem to think.
- colinbartlett 7y ago
  I’m working on a thing I’m calling DriftWatch that attempts to track, objectively, how far out of date you are on dependencies, which I call dependency drift. I’ve posted about it here before [1]. I’m using it in my consulting practice to show clients the importance of keeping up to date and it’s working well. I agree with the parent that it’s important to lock to avoid surprises (in Ruby, we commit the Gemfile.lock for this reason), but it’s equally as important to stay up to date. 1. https://nimbleindustries.io/2020/01/31/dependency-drift-a-metric-for-software-aging/ https://nimbleindustries.io/2020/01/31/dependency-drift-a-me...
  - thawkins 7y ago
    There are commercial tools like blackduck, sonartype/nexus which are used to sczn dependancies of not1 just node code, and highlite ourof date packages, known vulnerabilities, and license problems.
- montroser 7y ago
  Well, I guess you can choose whichever poison you like. Pinning isn't meant to be a forever type of commitment. You're just saying, "all works as expected with this particular permutation of library code underneath." And the moment your dependencies release their hot-new you can retest and repin. Otherwise you're flying blind and this type of issue will arise without fail.
- jessaustin 7y ago
  The "magical security updates" theory has never worked. Breaking insufficiently-pinned dependencies are vastly more common than unnoticed fixes on patch releases. On balance, semver has been good for javascript, but to the extent it contributed to the popularization of this dumb theory it has been bad. Production apps (and by a transitive relation, one supposes, library modules) should be zealously pinned to the fewest possible dependencies, and those dependencies should be regularly monitored for updates. When those updates occur, tests can be run before updating the pins.
wildpeaks 7y ago
Exactly: pin dependencies to avoid surprises, and use a CI to test compatibility of new versions, so you can deploy security updates on your own schedule, best of both worlds. Github even bought Dependabot last year, so it's now free.

tgv 7y ago

> pin your dependency versions And then to see "npm detected 97393 problems" or whatever the message exactly is.

acdha 7y ago
That’s good: it’s easy to update and it means you do it in a controlled manner rather than the next time something deploys.
montroser 7y ago
You don't need to pin them forevermore -- just when you don't want everything to break unexpectedly :). When you want to upgrade your dependencies, then go ahead and do that, on your own schedule, with time and space to fix whatever issues come up, update your tests, QA, etc.

mikewhy 7y ago

> pin your dependency versions for projects running in production Works for existing apps, but people using create-react-app and angular CLI can't even start a new project.

staticassertion 7y ago
I don't know much about those projects, but why did this break them? Are they not pinning versions?
- yandie 7y ago
  Because they are starting a new project from scratch and would have nothing to pin their dependencies against?
  - staticassertion 7y ago
    Maybe I'm misunderstanding how those projects work. From what I recall, they generate a project, including the package.json. So I'm not sure why they couldn't just generate the package.json with pinned versions? I don't write much JS, and have only used create-react-app just a few times, so feel free to explain why this isn't possible.
    - mikewhy 7y ago
      package.json only lists top-level dependencies. package-lock.json tracks all dependencies, and dependencies of dependencies. is-promise is one of those dependencies of a dependency, which you don't have much control over.
      - rsanek 7y ago
        How could a dependency-of-dependency change version if one of the direct dependencies doesn't change version? I guess, if the direct dependency isn't pinning that version? Another case of, everyone should be pinning dependencies.
        mikewhy 7y ago
        Exactly, node's conventions are to allow a range of versions (semver compatible). True, if all dependencies were pinned, this wouldn't come up as often. That also means that there would be a lot more updating when security issues are found.
      - staticassertion 7y ago
        How would a top level dependency change versions if it bumped a transitive dependency? Is that a thing in js-land?
montroser 7y ago
Nah, create-react-app and others could easily pin dependencies of libraries they install in your new project to known-good versions. Without doing that bit of diligence, this type of issue should be 100% expected.
- mikewhy 7y ago
  By doing that they would avoid this issue, for sure. They would also introduce security issues by using old versions. And this would do nothing for the fact that `npm install eslint && ./node_modules/.bin/eslint` was also failing.
  - montroser 7y ago
    It's not like pinning means you can /never/ update. You just get to do it on your own schedule. You can even automate updating to some degree -- running your tests against the latest everything and then locking in to those versions of all goes well.
    - mikewhy 7y ago
      Again, this only works for project skeletons, and not for any other package that happened to have a transient dependency on `is-promise` (which is a lot more than project skeletons).
  - tirpen 7y ago
    Pinning dependencies might introduce security issues. Not pinning dependencies is a security issue.
- oefrha 7y ago
  Then you can’t upgrade anything unless create-react-app releases a new version (or you eject), which, in addition to the obvious release cadence problem, might introduce other compatibility problems.

2OEH8eoCRo0 7y ago

I'm a novice in this area but if your project relies on a bunch of external node packages why wouldn't you download them all and host them locally or add them to version control?

winrid 7y ago
You'd use a proxy, yes.
IAmEveryone 7y ago
Adding them to your own version control is a nightmare: Your own work will drown in all the changes in your dependencies. The repository will quickly grow to gigabytes, and any operation that would usually take seconds will take minutes. It's also just not needed. Simply specifying an exact version ("=2.5.2") will avoid this problem. The code for a version specified in this manner does not change.
- montroser 7y ago
  Yes, putting your dependencies in version control alongside your project is no fun. Commit history is muddied, but also if your production boxes are running on a different platform or architecture than where you and your team develop, that can make a big mess too. That said, with a big enough team and risk-averse organisation, it can be a brilliant idea to put your dependencies in /separate/ version control and have your build process interact that way. In that scenario, even if your dependencies vanish from the Internet (as happened with left-pad), you are still sitting pretty. You can also see exactly what changed when, in hunting for causes of regressions etc.
- 2OEH8eoCRo0 7y ago
  To me an even bigger nightmare is your entire project or product depending on some external resource you don't control.
jdlshore 7y ago
Checking them into your repo is called “vendoring” and it’s one way of solving the problem, yes. Personally, it’s my favorite approach. But it does have some challenges, as other commenters point out.

btilly 7y ago

And everyone who depends on projects that pin their dependency versions gets to be victims of security exploits long after they are fixed. Dependency management is not as simple as you seem to think.

colinbartlett 7y ago
I’m working on a thing I’m calling DriftWatch that attempts to track, objectively, how far out of date you are on dependencies, which I call dependency drift. I’ve posted about it here before [1]. I’m using it in my consulting practice to show clients the importance of keeping up to date and it’s working well. I agree with the parent that it’s important to lock to avoid surprises (in Ruby, we commit the Gemfile.lock for this reason), but it’s equally as important to stay up to date. 1. https://nimbleindustries.io/2020/01/31/dependency-drift-a-metric-for-software-aging/ https://nimbleindustries.io/2020/01/31/dependency-drift-a-me...
- thawkins 7y ago
  There are commercial tools like blackduck, sonartype/nexus which are used to sczn dependancies of not1 just node code, and highlite ourof date packages, known vulnerabilities, and license problems.
montroser 7y ago
Well, I guess you can choose whichever poison you like. Pinning isn't meant to be a forever type of commitment. You're just saying, "all works as expected with this particular permutation of library code underneath." And the moment your dependencies release their hot-new you can retest and repin. Otherwise you're flying blind and this type of issue will arise without fail.
jessaustin 7y ago
The "magical security updates" theory has never worked. Breaking insufficiently-pinned dependencies are vastly more common than unnoticed fixes on patch releases. On balance, semver has been good for javascript, but to the extent it contributed to the popularization of this dumb theory it has been bad. Production apps (and by a transitive relation, one supposes, library modules) should be zealously pinned to the fewest possible dependencies, and those dependencies should be regularly monitored for updates. When those updates occur, tests can be run before updating the pins.

wildpeaks 7y ago

Exactly: pin dependencies to avoid surprises, and use a CI to test compatibility of new versions, so you can deploy security updates on your own schedule, best of both worlds. Github even bought Dependabot last year, so it's now free.