| ▲ | egorfine 4 days ago |
| > Don't update dependencies unless necessary And get yourself drowning in insurmountable technical debt in about two months. JS ecosystems moves at an extremely fast pace and if you don't upgrade packages (semi) daily you might inflict a lot of pain on you once a certain count of packages start to contain incompatible version dependencies. It sucks a lot, I know. |
|
| ▲ | lpribis 4 days ago | parent | next [-] |
| Updating packages daily (!) is insane to me as someone from the other end of the programming spectrum (embedded C). Is this really the recommended practice? |
| |
| ▲ | DecoySalamander 3 days ago | parent | next [-] | | It really isn't, and I've never seen anyone do that. In every project I've worked on in the past decade, dependencies were only occasionally bumped in the context of some maintenance task or migration. | |
| ▲ | egorfine 4 days ago | parent | prev | next [-] | | It is insane to me as a C programmer as well. It is something I got used to as a frontend js developer. It so recommend to stay on top of the dependencies and for different stacks this means different update schedule. For some, daily is indeed a good choice. | | |
| ▲ | 1718627440 3 days ago | parent [-] | | Even if there is a new version every day, not every release is born equal. Wouldn't updating while developing to "stay on top of dependencies" only be necessary on a major version? Surely there is not a major version per day. I mean otherwise you would use a library, that constantly imposes work on you and it would probably make more sense to write the library yourself. Minor versions and bugfixes can be incorporated when you do your release. | | |
| ▲ | egorfine 2 days ago | parent [-] | | All I want to say is that it's truly cheaper to upgrade and test daily in the world or javascript. Seriously, it breaks rarely and you can immediately spot what exactly failed and fix it right away. Upgrading after a month will take some serious time. |
|
| |
| ▲ | acdha 4 days ago | parent | prev [-] | | It varies but there are a lot of tools built around the idea of rapid updates so things like APIs can change quickly throughout a far more fragmented ecosystem. I suspect that we’re going to see a lot of places back off of that a bit to have something like monthly update cycles where there’s more time for scanning and review while still expecting people to upgrade more frequently than used to be common. |
|
|
| ▲ | gslepak 4 days ago | parent | prev [-] |
| > daily Somehow we've survived without updating dependencies for probably at least a year. |
| |
| ▲ | egorfine 3 days ago | parent [-] | | Then you probably have over a dozen CVEs in your code. Now, this is a different question whether they are exploitable and how much it is a risk. Other than that you now probably have an insurmountable technical debt and upgrading the dependencies is a project of itself. All the above applies to JavaScript world, of course. It's much different for the rest. | | |
| ▲ | gslepak 3 days ago | parent | next [-] | | > Then you probably have over a dozen CVEs in your code. We continuously monitor our dependencies for CVEs and update them if necessary. Most of the time the CVEs that are reported are not relevant / worth updating for. | |
| ▲ | yread 3 days ago | parent | prev | next [-] | | content-security-policy: default-src 'self';
(and not sending crypto transactions): No need to worry about CVEs in js | |
| ▲ | 1718627440 3 days ago | parent | prev [-] | | If a library introduces CVEs per day, it's probably not so good to begin with. |
|
|