Comment by zelphirkalt
2 months ago
Most dependencies do much more than we need from them. Often it means we only need one or a few functions from them. This means one doesn't need to rewrite whole dependencies usually. Don't use dependencies for things you can trivially write yourself, and use them for cases where it would be too much work to write yourself.
A brief but important point is that this primarily holds true in the context of rewriting/vendoring utilities yourself, not when discussing importing small vs. large dependencies.
Just because dependencies do a lot more than you need, doesn't mean you should automatically reach for the smallest dependency that fits your needs.
If you need 5 of the dozens of Lodash functions, for instance, it might be best to just install Lodash and let your build step shake out any unused code, rather than importing 5 new dependencies, each with far fewer eyes and release-management best practices than the Lodash maintainers have.
The argument wasn’t to import five dependencies, one for each of the functions, but to write the five functions yourself. Heck, you don’t even need to literally write them, check the Lodash source and copy them to your code.
This might be fine for some utility functions which you can tell at a glance have no errors, but for anything complex, if you copy you don't get any of the bug/security fixes that upstream will provide automatically. Oh, now you need a shim of this call to work on the latest Chrome because they killed an api- you're on your own or you have to read all of the release notes for a dependency you don't even have! But taking a dependency on some other library is, as you note, always fraught. Especially because of transitive dependencies, you end up having quite a target surface area for every dep you take.
Whether to take a dependency is a tricky thing that really comes down to engineering judgement- the thing that you (the developer) are paid to make the calls on.
1 reply →
And then when node is updated and natively supports set intersections you would go back to your copied code and fix it?
2 replies →
You have obviously never checked the Lodash source.
6 replies →
Yes, fewer, larger, trustworthy dependencies with tree shaking is the way to go if you ask me.
Almost like a standard library..
2 replies →
I think the level of protection you get from that depends on how the unused code detection interacts with whatever tricks someone is using for malicious code.
I agree with this but the problem is that a lot of the extra stuff dependencies do is indeed to protect from security issues.
If you’re gonna reimplement only thr code you need from a dependency, it’s hard to know of the stuff you’re leaving out how much is just extra stuff you don’t need and how much might be security fixes that may not be apparent to you but the dependency by virtue of being worked upon and used by many people has fixed.
I'm using LLMs to write stuff that would normally be in dependencies, mostly because I don't want to learn how to use the dependency, and writing a new one from scratch is really easy with LLMs.
Age of bespoke software is here. Did you have any hard to spot non-obvious bugs in these code units?