To illustrate the problem: my dom-css module[1] needs a method to convert to camel case.
I could copy-paste from stack overflow, but I would have to maintain/test that function. I'd rather depend on something.
I could depend on a big "string-utils" library, but that would probably carry some useless baggage, and its scope may change or grow over time. Further, maybe it has a competitor module with a vehement following (like lodash vs underscore), which makes my module less appealing to them. This sucks for my module because I just want that one function.
The better alternative is just to depend on the exact, clearly named "to-camel-case" function which is very unlikely to ever change or grow in scope.
If the to-camel-case function never changes or grows in scope, then you don't need to maintain or test it.
If it does change, then you need to integrate & test your dependencies, same as if it were part of your own codebase.
I think this point is often overlooked by the "I'll use someone else's code because I don't want to maintain it" folks. Code that is frozen doesn't rot: if you never change a piece of code and don't change its dependencies, it will continue working. Similarly, usually the reason you'd in-source a library is so you can change it at-will without getting some other maintainer to accept your patches. Most of the time, the effort that you save by using 3rd-party code is exactly equal to the time it would take to write & debug the library to get it to its current state, minus the time spent hunting for, learning, and integrating the library. Both of these are pretty easy to estimate when it's a one-line function; does it take you longer to find and npm install that one-line function than it does you to write a line of code?
There's a cohesive social element to "many small modules" that fosters a community.
Module authors work with and respect each other.
Most of the time, the effort that you save by using 3rd-party code is exactly equal to the time it would take to write & debug the library to get it to its current state, minus the time spent hunting for, learning, and integrating the library.
There are plenty of small functions that might be a little trickier than is first imagined. Time isn't the only issue. There's also much less cognitive overhead in the two minutes it takes to search npm, figure out the interface, install the module, and use it. I'd much rather outsource my yak shaving.
I wouldn't copy paste some random blog or SO code without first writing a test for it.
My dependencies already have tests, so I have no need to re-write them. When my tests do fail it is usually immediately clear where the problem lies since things are isolated.
In regards to time; it might take 1-2 minutes to find a module, and then 0 minutes the next time I need the same module. Compared to 1-2 minutes of writing/copy-pasting, a lot of time spent refining/fixing the code as edge cases are found, and then more time spent the next time that function is needed in another module.
This workflow has evolved through my own experiences with modules over the last couple years. I used to do a lot of copy-pasting and "kitchen sink" libraries, but now I find it much more efficient and better in the long run to isolate code. Just a few examples that would be a pain to maintain and rewrite in each project that uses them (potentially dozens):
You also get the benefit of code that builds on its dependencies, like "lerp-array" which depends on lerp, and "line-circle-collision" which depends on "point-circle-collision".
Linking functions; but also minimizing scope creep, API changes, opinionated libraries with a questionable lifespan, bit rot, and versioning woes (eg. a major change in to-dash-case may not represent a major change in to-camel-case).
I could copy-paste from stack overflow, but I would have to maintain/test that function. I'd rather depend on something.
I could depend on a big "string-utils" library, but that would probably carry some useless baggage, and its scope may change or grow over time. Further, maybe it has a competitor module with a vehement following (like lodash vs underscore), which makes my module less appealing to them. This sucks for my module because I just want that one function.
The better alternative is just to depend on the exact, clearly named "to-camel-case" function which is very unlikely to ever change or grow in scope.
[1]https://npmjs.com/package/dom-css