Earlier quoted context omitted.
> Why waste time and lines of code implementing something so trivial when there is already a solution available? Because it's so trivial? I can't wrap my head around why this is an argument in the first place. It makes no sense to bring in a module from a third party adding yet another dependency and potential point of failure when reimplementing it yourself literally takes as long as it takes to find the module, add…
> It makes no sense to bring in a module from a third party adding yet another dependency and potential point of failure when reimplementing it yourself literally takes as long as it takes to find the module, add it to package.json and run npm install. Even if it does take the same amount of time (which it shouldn't), a 1-line call to a standard module imposes less of a future maintenance burden than 14 lines of cust…
In my experience with using npm since it's release, module authors will spit out modules very quickly then, after some period of time, abandon them without passing them onto other people. At which point I have to assume all future maintenance anyway. This has happened to me so many times, in fact, that I try to make even picking my dependencies based on the author's interests. For example if it's owned by a company or organization that still uses the module then it's usually one of the safest to pick.
Regardless I don't think I'd ever call very elementary code a "maintenance burden". Ever.
> That's a non sequitur. Reproducible builds are important, but unless you write code with 0 external dependencies you already have a system in place for handling library dependencies in a reproducible way. So why not use it?
Completely disagree here. As we saw with this "npm gate", even if you're using a shrinkfile, npm doesn't completely provide handling dependencies in a reproducible way. Not always. Maybe most of the time though our build server certainly has logs where npm was unreachable, having issues, etc on a very regular basis.
The point being: where it's possible to mitigate and remove dependencies I think you'd be crazy not to. Every dependency you can lose is another potential build issue or attack surface you're removing from your project.
> This is the opposite of my experience.
That's fine. In my experience people will take DRY so far that even meta data and comments will be abstracted so you can't even understand a piece of code without opening multiple files. I think it's perfectly reasonable to repeat yourself at times but those cases where you have to open up 5 files just to understand what a REST endpoint accepts as input is crazy.
I think DRY in general is fine as long as it's not used as an absolute "we have to do it this way because DRY". :)