4 ms·
> What might not be a great idea is to have 1600 dependencies in 2024, dependencies which already change at such a rapid clip your code base is effectively a mo
by tasuki 2y ago
> What might not be a great idea is to have 1600 dependencies in 2024, dependencies which already change at such a rapid clip your code base is effectively a moving target.
Has the author not heard about reproducible builds? Why would you care that your dependencies change?
> Dependencies...
> Drift away, leading to adjustments in your code or, worse, silent changes in behaviour
> Shift to new major versions with semantic changes, requiring rewrites on your part
> Get abandoned or simply disappear, or start to decay
Really, these aren't things that can affect you at all if you have reproducible builds!
> Tests are always a good idea, especially if you have many dependencies which shift and drift all the time.
Not a thing! If your dependencies "shift" or "drift", you're doing it wrong!
- perlgeek 2y agoEven when you have reproducible builds and local copies of all recursive dependencies, you have to be able to react when e.g. a security vulnerability is found in one of them. If you have 1600 of them, you probably don't know them all very well, so you might already be in trouble in the assessment stage. If there's a fix upstream, you might need to update to the newest version, and that in turn might force you to upgrade more dependencies, or introduce new ones etc. Reproducible builds are great, but they aren't a panacea for dependency hell.
- tasuki 2y agoYes, security vulnerabilities are about the only case when you have to react. The kinds of libraries that can introduce security vulnerabilities (crypto, networking, etc) are hard to write by yourself. If you do happen to write that code by yourself -- to minimize dependencies -- chances are it's full of security holes anyway. Security is hard!