At risk of criticism, I'll bite. I used to think this way and include a lot of small dependencies in most projects I worked on.
The thinking was as follows: Of course you could just copy the code, but then that increases LOC in my codebase that I'm responsible for. More code is more work. Lines in a dependency are the responsibility of someone else. If there's a bug, even in a small function, the community can identify it and fix it. I can get new features I might not have known I needed. I can benefit from all of these fixes indefinitely into the future without ever having to have any mental overhead about that code. So can everyone else; it's good to maximize code reuse.
I don't think I've ever used something that could be an obvious one-liner like `isOdd` but for lots of only slightly more complex stuff like left-pad, email format validation, GPS coordinate math functions -- all stuff that's really less than 30 lines -- it was really nice to just not have to think about the implementation details of that and get back to solving your problem. I could have reviewed the code or written it myself but it's just more work when remaining at a high level `leftPad()` call let's me stay focused on my original task.
That said, I've since realized I was wrong of course. Trying to maintain projects that haven't been touched in more than a year led to hours of fixing dependency issues. We switched to using dependabot, which is better, but just makes it obvious how much work it actually is to keep dependencies up to date week-to-week. Then there's all of the security issues. These days, for small packages, I advocate for reviewing the code from these packages, ensuring we understand it, and then copying it in directly with a comment for attribution. We generally try to keep dependencies low; still more than in other languages but at least some thoughtfulness about whether it's "worth it". I think a lot of the community has shifted similarly, but there's still a lot of older projects with older dependencies.
> Of course you could just copy the code, but then that increases LOC in my codebase that I'm responsible for.
Once your company is owned by a supply chain attack or by an RCE in one of your dependencies, you will learn that you are in-fact very much responsible for the code in your external dependencies.
This drives me crazy. If your software is using a library that library is part of your software whether you originated its code or not. If you are responsible for the software then you're responsible for the LOC in every library your software depends on.
The thinking was as follows: Of course you could just copy the code, but then that increases LOC in my codebase that I'm responsible for. More code is more work. Lines in a dependency are the responsibility of someone else. If there's a bug, even in a small function, the community can identify it and fix it. I can get new features I might not have known I needed. I can benefit from all of these fixes indefinitely into the future without ever having to have any mental overhead about that code. So can everyone else; it's good to maximize code reuse.
I don't think I've ever used something that could be an obvious one-liner like `isOdd` but for lots of only slightly more complex stuff like left-pad, email format validation, GPS coordinate math functions -- all stuff that's really less than 30 lines -- it was really nice to just not have to think about the implementation details of that and get back to solving your problem. I could have reviewed the code or written it myself but it's just more work when remaining at a high level `leftPad()` call let's me stay focused on my original task.
That said, I've since realized I was wrong of course. Trying to maintain projects that haven't been touched in more than a year led to hours of fixing dependency issues. We switched to using dependabot, which is better, but just makes it obvious how much work it actually is to keep dependencies up to date week-to-week. Then there's all of the security issues. These days, for small packages, I advocate for reviewing the code from these packages, ensuring we understand it, and then copying it in directly with a comment for attribution. We generally try to keep dependencies low; still more than in other languages but at least some thoughtfulness about whether it's "worth it". I think a lot of the community has shifted similarly, but there's still a lot of older projects with older dependencies.