This is exactly the reason I kinda hate Node projects. I watched grimly as no less than four versions of lodash/underscore were pulled in during a project install.
People, learn your damn standard libraries.
haha I just wrote an internal post called “Lodash Functions We Probably Shouldn’t Use” for exactly this reason
Tree shaking amounts to whole-program analysis prove certain code is never going to be called and removing it from the delivered artifact. During development, don’t bother. But a production build performs the tree shaking.
Also Rollup and Webpack 2 for non-Java tools. :-)
Interesting to see voices in the Ruby community starting to push for simple over easy.
[Comment removed by author]
or worse! ;)
Part of your job as a library author is to treat your user and their application with respect
“Job” you say?
Counter-proposal: As a library author maintaining a project in your unpaid spare time, do whatever you damn well please to make your life easier. If a commercial entity is desperately upset that the product they got for free and are making money through using is adding 10MB to their runtime footprint, they’re welcome to spend some time or money getting a patch in to fix this.
I mean, this isn’t bad advice. I actually mostly follow it myself (my primary project, Hypothesis, has zero external dependencies except for standard library backports), but asking people to do even more free work than they’re already doing so that the people making money off said free work have a slightly easier time of it really grinds my gears.
Meh. 10mb of ram. Who cares? Evidently not many people, because anyone who cared would have profiled their memory usage and found the culprit pretty easily.
Work with the tools that you have. Pruning your dependencies is one of those things like reformatting all your code according to a style guide - occasionally valuable, but often a disproportionate use of programmer effort.
Code reuse is as bad as rewriting everything yourself…
I’d say use external dependencies liberally in development; look at getting rid of them during refactoring phases. it may or may not ultimately make sense to include an entire library for one function, but being able to use that function rather than having to write it yourself while developing your code is a valuable thing.
I think a lot of this is failure on package management as well. These languages encourage using non-system libraries by making it trivial to add chains of external packages, encouraging waste.
There are also other issues with dependencies:
All in all, pulling in a dependency means putting a lot of trust in its maintainers. How many projects are worth trusting that much? Not many, I believe.