The cost of a dependency for a good package manager is zero, and the cost of not having that dependency is non-zero. So the problem is with NPM, not with adding a dependency.
NPM, like any package manager, pretty much blindly accepts user input. I, as a module maintainer, could happily change every single function in my modules to
function whatever() {
return "WHHEEEEEEE!!!";
}
Seriously, the properties of good package management should be obvious by now. Any design that can break dependents and there's nothing they can do to protect themselves is broken.
And pinning versions just means you lose automatic updates, which is surely the point of using a package manager in the first place. Otherwise you might as well just download the package and include it verbatim.
No True Scotsman is so often mis-attributed, that the mis-attribution needs to be its own fallacy.
My comment was against this belief that "smarter" tools in general are some sort of panacea.
For example pining to a specific version won't help you match if the package is removed altogether (as in this case), and ever worse if it's replaced afterwards by another (newly registered) with an incompatible same version out. It won't try to overwrite your specific install of course (since the version already matches what you have), but you'll feel the pain when you try to duplicate/deploy etc a new install with the same package listing -- suddenly the package either won't be there (or will be modified in the worst case scenario).
So, then we opt for ever more features of a "sufficiently smart package manager", e.g. signatures, permanence of anything published etc...
The point is that people use package managers and third party modules installed from them to automate tedious work, and anything automated will have the potential to do something other than what you want. Is that risk high? Not really, but it's not zero either.
As to curated package managers, I'd consider them a great counter-example. Try installing a recent (5.x) version of node and postgres (9.4) on ubuntu. You can go through the rigmarole of adding an entirely new repository for postgres (apt.postgresql.org) since the debian distributed version of postgres is rather old (and ubuntu-version specific). You can also do the same thing with nodesource for nodejs, but if you install node on ubuntu, you'll get a packet radio service instead.
Curated package managers are very conservative and move very slowly. Javascript is a relatively fast-moving, pretty anarchic environment.
The lesson of left-pad is probably: vendor your node deps and check them in. And also: npm probably needs to be replaced with a write-once store with cryptographic signing of packages. You still have to trust the author, but that's the point of open source. We're built on trust.
Not sure what your point is on postgres, since 9.4 is right there in the repo.
Node moves fast, sure. I'm not sure I agree with your "crazy breaking" modifier there: I regularly do dev work against the latest 5.x branch of node, and rarely if ever have to worry about breaking changes. Then again, I'm just doing plain old restful api and business logic stuff, so maybe if you're dealing with the c++ interface it's a different environment.
Even still, I think it's easy enough to see from our disagreement over "too fast" and "quite sensibly" that there's plenty of ways to be a programmer. Rapid improvement can be kind of exhausting (especially if you get behind) but it's also a great way to see new ideas emerging. One of the things I actually love about the javascript world is how quickly things move. Things evolve very quickly because there's so much churn, speedy releases, pressure for mindshare, and so on. It's fascinating, both technologically and sociologically.
It ought to be pretty straightforward to say "apt-get install nodejs-5.3" and have that Just Work, but by the time the curators get around to updating their packages, you may well be a month or three behind. (again, unless you've updated your sources.list.d to include the nodesource repo).
So yeah: curated package managers have a place in the world for sure. But the trade-off here is that you're not getting the Latest and Greatest. Joyent tried to Slow Things Down with the 0.10 branch of node, and you see where that got them.
About the only good thing that comes from this is that we get to laugh out loud every half a year when there's a random GitHub outage and those companies all scream bloody murder.
The recent left_pad fracas has proved that that is not the case. Snapshot dependencies in-tree? Sure. But a package manager based dependency will be predicated on trusting a lot of things.
For the record, I believe that npm is a pretty good package manager. And the dependency cost I talk about is universal -- any package manager that allows for easy package updates is open to critical packages being broken. Removing the "unpublish" feature (and using something like Cargo's yank) makes it harder for left_pad like incidences to happen, but you still have issues with broken package updates, etc. You can further solve this with global version pinning, but not everyone will do this so you're still stuck.
That's great, and my point was that with a good package manager, that cost is effectively zero.
> And the dependency cost I talk about is universal -- any package manager that allows for easy package updates is open to critical packages being broken.
Automatic updates are a terrible idea, even if the developer purports to use "semantic versioning" and the update is supposed to be backwards compatible. Specifying a version should be mandatory.
Your package manager could easily notify you that updates are available, but it should never update for you. That's as "easy" as updates should get, because anything else inevitably introduces silent breaking changes.
yes, which doesn't refute pdkl95's point. If you're not in the world with a good package manager, you should consider the cost of the dependency. The Node ecosystem seems to not have done that. That's the bottom line here, if there is a cost to dependencies (which you don't seem to disagree with, at least wrt NPM), then you shouldn't have dependencies for 11-line functions. Everything else is orthogonal.
just saying be an engineer. weigh the costs
It's a lot like DLLs/shared libraries, actually: people marshal the same old arguments every time explaining why they are a great idea in theory, but in practice, there seems to be a whole hell of a lot of work being done to make up for the fragility you bring on board with a system like that, and I'd rather just embed the source or link it statically (depending on which context we're talking about here) so that I don't have to waste any time thinking about it.
I disagree. Another non-zero cost that I don't see mentioned yet is a licensing cost. What if there is some GPL'ed code somewhere in the dependency chain, but you don't know it because you are using code that uses GPL code but didn't realize it? Using lots of dependencies is just asking for licensing hell
Only if one doesn't understand the notions of opportunity cost, code debt, and several other things besides...