Live data from Hacker News

Left-pad as a service

left-pad.io

81–90 of 269 posts

Re: Left-pad as a service

#81
post #72

Earlier quoted context omitted.

> This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. 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.

"Zero" isn't a cost of anything -- there's no free lunch. 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!!!"; } and check it in. Doing that will result in no fewer problems than just deleting the module entirely, and it's not NPM or any other similar package manager's…

Except a good package manager will let you specify exactly which version you wish to depend upon, so any changes you make upstream will have no effect on people who protect themselves against automatic version updates.

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.

Re: Left-pad as a service

#83
post #80
post #52

Earlier quoted context omitted.

The Java standard library is anemic? As in Java SE? That's rich. Java SE is an everything but the kitchen sink standard library, with functionality like collection classes, local and networking IO, windowing toolkits (more than one), database connectivity, the list goes on. There is no language with a less anemic standard library, and Java SE is often criticized for being too large.

This is true. One wonders if OP has actually seen the vastness of Java SE or is just "hating" to "hate".

I've seen it, and more often than not frustratedly turned to Apache Commons because the Java standard library is as vast as it is useless.

Re: Left-pad as a service

#84

Earlier quoted context omitted.

> The cost of a dependency for a good package manager is zero 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.

I said a good package manager. The fact that the npm package database is fully mutable is a huge problem.

That still isn't enough to refute "The reason so many people are criticizing left-pad et al is about the cost of adding a dependency.". Sure, npm may be a bad package manager. If you do have a bad package manager, there is a cost of adding a dependency, and you should consider it. That's what pdkl95's point was. Most other ecosystems, with good or bad package managers, do not have tiny one-function packages -- it's possible to have an ecosystem not depending on it. If npm isn't good enough to have zero-cost dependencies, then your ecosystem should definitely not depend on tiny packages. This may be NPM's fault, but it's the fault of the ecosystem too.

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.

Re: Left-pad as a service

#85
post #72

Earlier quoted context omitted.

> This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. 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.

"Zero" isn't a cost of anything -- there's no free lunch. 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!!!"; } and check it in. Doing that will result in no fewer problems than just deleting the module entirely, and it's not NPM or any other similar package manager's…

Yes, but a sanely designed package manager will at least require that to be a new, versioned release. _Already published_ versions of a package should be immutable.

Re: Left-pad as a service

#86

Earlier quoted context omitted.

its called self-regulation. Each community has its own quirks and extremes as seen by everyone else. Without the bashing, they would become even more extreme. At least after this a lot of devs will think twice about making "micro-modules".

If that were true java would have started dying a few years ago, javascript frameworks wouldn't pop up every week, and most people would use shell scripts instead of build tools. This is exactly the kind of flame war stuff the guidelines seem to have tried to stop.

Just a data point, but our shop has been moving away from a lot of the more heavy Spring features, and splitting our Java code into simpler microservices. I think the points about overabstraction are getting through slowly.

Re: Left-pad as a service

#87
post #64
post #47

Earlier quoted context omitted.

> How stupid of people to reuse small often used functions that only do one thing well. This is a straw man argument. The reason so many people are criticizing left-pad et al is about the cost of adding a dependency. > trust their package manager That's exactly the problem: you're assuming that a package manager can be trusted. The network isn't reliable, packages can changed innocently or maliciously, and mistakes h…

>The network isn't reliable, packages can changed innocently or maliciously, and mistakes happen. Exactly. I'd like to know if andy_ppp reviews every update to packages that andy_ppp wants to include too.

Yes, I agree with you - there will always be some level of trust involved in your package manager. I think having a better standard library is probably the first desired solution, followed by npm keeping all old versions of a module around even after unpublishing and also some kind of review process build management system magic as part of your code review process.

It's all very easy to say of course and loads of people having been saying including small piece of code from your package manager is wrong. I'm saying it's not and giving reasons why. Trust your package manager or help make it trust worthy I guess.

Re: Left-pad as a service

#88
post #8

Hahaha - isn't it hysterical how everyone using npm for small reusable code pieces! Aren't they morons! How stupid of people to trust their package manager to be consistent and correct and return packages they were expecting. How stupid of people to reuse small often used functions that only do one thing well. How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM…

> It's not javascript devs fault that the standard library is so piss poor you need these short code snippet

Well, they could use a better language which compiles to Javascript …

Re: Left-pad as a service

#89
post #30

Earlier quoted context omitted.

>How does everyone taking the piss intend to protect themselves from this in their OS package manager, or PPM or composer or pip? By signing packages and not allowing literally anybody to re-upload a brand new package that does something completely different under the name of an existing, widely-used package. There's not much excuse for that in any respectable package manager.

Okay so have you checked all of the apt repos you've added to sources over the years or has one of the ppa's changed to something malicious?

I've added exactly 0 apt sources, precisely because relying on ppas and the like is terribly, terribly insecure. Allow some random person to run code on my machine as root — that's insane.

Re: Left-pad as a service

#90
post #72

Earlier quoted context omitted.

"Zero" isn't a cost of anything -- there's no free lunch. 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!!!"; } and check it in. Doing that will result in no fewer problems than just deleting the module entirely, and it's not NPM or any other similar package manager's…

Except a good package manager will let you specify exactly which version you wish to depend upon, so any changes you make upstream will have no effect on people who protect themselves against automatic version updates. 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.

That's just a no-true-scotsman fallacy.

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.

Post reply on HN