4 ms·

Unless you just... Keep using the old version of the framework? No one is making you upgrade

jonnyasmar 5mo ago
You can, and sometimes that's the right answer. Where it gets hard: security CVEs that need patching but the fix is only in the new major, transitive deps that bump and bring incompatibilities, hiring a contractor who doesn't know your locked version. None of those are insurmountable, but they're real tax.
em-bee 5mo ago
the problem is that you have to keep all the artifacts around so you can keep building with the old framework. especially in the npm world that is incredibly annoying. my solution for javascript at least is to avoid build tools alltogether, and build the site in such a way that it runs without a build step only using frameworks that support that. since the code runs in the browser there are no security concerns because you can't trust that code anyways.
- materielle 5mo ago
  Which brings us to the next layer of modern dependency management insanity: The fact that basically none of these multi-million dollar companies are vendoring their entire dependency tree. At most companies, even ones worth millions of dollars, it would be impossible for them to rebuild their software if someone ripped a package off of npm’s registry or whatever.
lmm 5mo ago
Until you run out of hardware that can run an OS old enough that the old version of the framework works, sure. Even then, you may find it hard to add new dependencies without getting current on the framework, since most ecosystems require you to pick a winning version in the case of a "diamond" transitive dependency.
- singpolyma3 5mo ago
  Well if you're adding new dependencies you're already doing new maintenance work and this is a while different ballgame than just to keep what you have working.
  - lmm 5mo ago
    Yes and no. In practice sooner or later you need to update something - you need it to work with a new OS/database/TLS algorithm - and then often there's a domino effect.

You can, and sometimes that's the right answer. Where it gets hard: security CVEs that need patching but the fix is only in the new major, transitive deps that bump and bring incompatibilities, hiring a contractor who doesn't know your locked version. None of those are insurmountable, but they're real tax.

em-bee 5mo ago

the problem is that you have to keep all the artifacts around so you can keep building with the old framework. especially in the npm world that is incredibly annoying. my solution for javascript at least is to avoid build tools alltogether, and build the site in such a way that it runs without a build step only using frameworks that support that. since the code runs in the browser there are no security concerns because you can't trust that code anyways.

materielle 5mo ago
Which brings us to the next layer of modern dependency management insanity: The fact that basically none of these multi-million dollar companies are vendoring their entire dependency tree. At most companies, even ones worth millions of dollars, it would be impossible for them to rebuild their software if someone ripped a package off of npm’s registry or whatever.

lmm 5mo ago

Until you run out of hardware that can run an OS old enough that the old version of the framework works, sure. Even then, you may find it hard to add new dependencies without getting current on the framework, since most ecosystems require you to pick a winning version in the case of a "diamond" transitive dependency.

singpolyma3 5mo ago
Well if you're adding new dependencies you're already doing new maintenance work and this is a while different ballgame than just to keep what you have working.
- lmm 5mo ago
  Yes and no. In practice sooner or later you need to update something - you need it to work with a new OS/database/TLS algorithm - and then often there's a domino effect.