Comment by BinaryIdiot
11 years ago
> 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 custom code.
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". :)
> Regardless I don't think I'd ever call very elementary code a "maintenance burden". Ever.
Every line is another line that maintainers have to read and understand.
> 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.
Disagree. If there are issues with npm shrinking not working then you absolutely need to resolve them - but resolving them is an O(1) problem no matter how many dependencies you have. Just like if you've already written a good general-purpose sorting function, there's no point writing a separate integer sort routine, even if the implementation could be simpler than the general-purpose one. You already depend on your packaging/dependency tools, so you might as well use them all the time.
> Every line is another line that maintainers have to read and understand.
Seriously? This is what you're going with? We're talking about very simple, elementary programming. To be worried about maintaining code that you learn how to do in the first few classes of any programming 101 class is absolute insanity.
> Disagree. If there are issues with npm shrinking not working then you absolutely need to resolve them
Can't resolve them if the module disappears or is replaced with a malicious module. Nor if you or npm are having connectivity issues (which, on the npm side, happens very frequently).
> Just like if you've already written a good general-purpose sorting function, there's no point writing a separate integer sort routine, even if the implementation could be simpler than the general-purpose one.
Not sure what you're getting at. If you need a sorting function you can probably use whatever is built into the language unless you need to sort across a distributed data set in which case write something or find a dependency to use.
> You already depend on your packaging/dependency tools, so you might as well use them all the time.
Absolutely, unequivocally, no. What you're saying is you should install and use dependencies, from third parties which you do not know anything about, for every single, possible thing just so you can use the tools "all the time". That's so irresponsible and backwards.
Use the tools for the job they were meant to be used for. Need a dependency because someone can do it better / faster / cheaper then you? Then grab it by all means. But don't use it for every tiny function and for loop just because you want someone else to maintain it.
> Seriously? This is what you're going with? We're talking about very simple, elementary programming. To be worried about maintaining code that you learn how to do in the first few classes of any programming 101 class is absolute insanity.
Every line is a maintenance burden - just reading and understanding the code is what takes most of the time. Lines of code (and notably not any measure of "complexity" of those lines that's been tried) is the one thing that correlates with bug rates.
> Can't resolve them if the module disappears or is replaced with a malicious module. Nor if you or npm are having connectivity issues (which, on the npm side, happens very frequently).
So figure out a process and resolve that, once and for all. There's no point just cutting 10% (say) of your dependencies and hoping that you won't encounter the problem on your more important dependencies.
> Use the tools for the job they were meant to be used for. Need a dependency because someone can do it better / faster / cheaper then you?
That's exactly why people were depending on this library.
2 replies →