Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Everything NPM Package

socket.dev

Post reply on HN
Print view View original

41–50 of 155 posts

Re: The Everything NPM Package

#41

Post by feross »

ruune wrote: post #19

Just as a side note about the screenshot at the end. I think it's from this socket thing, but the supply chain security of a package that depends on literally anything on npm having a score of almost 50 really makes me think if that score is just artificially inflated on every other package. Can you even reach a score below 47?

Founder of socket here. npm has since unpublished the chunk packages that the 'everything' package depends on (or perhaps made them private), so those packages are no longer being taken into account in the package score.

You're right that a package that depends on literally everything would absolutely have a score of 0 in our system.

Re: The Everything NPM Package

#42

Post by Affric »

nosefurhairdo wrote: post #18
Affric wrote: post #5

What a dissatisfying non-apology of an apology. > First, just want to apologize about any difficulties this package has caused. No rationale. No shame. Just the word “apologize” in a sentence. Who downloaded it though? Surely as a dev if you download such a package it’s on you?

Perhaps NPM should apologize for shifting blame and failing to address the root cause. The wildcard "any version of dependency" preventing unpublish is clearly flawed. The "everything" package folks had no malicious intentions, and nobody would benefit from a long-winded, ashamed apology. If not for NPM's flawed unpublish policy the everything team would've unpublished to resolve the issue.

I agree to a large extent but I am not sure even rereading my comment that I can take that that’s what I am advocating for.

I just think it would have been good to give the “I was hoping to investigate X, I did not expect Y, I can see now that it was irresponsible to do X.”

I don’t think that’s particularly long winded.

Re: The Everything NPM Package

#43

Post by IshKebab »

forrestthewoods wrote: post #12
charlie0 wrote: post #10

Earlier quoted context omitted.

Devs working with core developers to create more 1st party packages would be a good start. I don't need 12 different implementations for sorting on Vue/React/[insert spa framework of the month]. I just need 1 really good sorting library. With it, we can move to less overall dependencies on random packages.

That’s a really good way to stagnate imho. I’d rather have 10 sorting libraries that each specialize or make different trade-offs than one library that tries to do everything. That said, you can still have a core set of “blessed” packages that serve the common needs.

I don't know, I think "batteries included" standard libraries got a bad reputation because Python's standard library is so full of crap, so lots of people thought the whole idea was fundamentally bad. But I think the correct conclusion is just that Python's standard library is bad.

Go has a big standard library too and it's mostly very well designed, useful and avoids fragmentation.

I think a similar thing happened with compiler warnings and C/C++. The language is error prone so people want warnings but a lot of the warnings don't have good solutions (e.g. signedness mismatches) so people tend to ignore them. Also they aren't easy to control, e.g. from third party dependencies.

So some people got the idea that warnings are fundamentally wrong and e.g. Go doesn't have them. But my experience of Rust warnings is that they are totally fine if done right.

Re: The Everything NPM Package

#44

Post by o11c »

bezier-curve wrote: post #31
o11c wrote: post #29

Earlier quoted context omitted.

[flagged]

> There's a reason I still am skeptical of calling client-side devs "actual programmers". Nothing in your comment actually supports this last jab at web developers. Can you elaborate? I imagine you can't because you're arrogantly posturing.

Programming is, fundamentally, the imposition of a chosen order upon the world. You can easily distinguish somebody who's new to programming by the lack of choosing or the lack of effective order, and I think it quite fair to call them "not yet a programmer" while they're in that phase.

Sure, theoretically web devs can be programmers. But in practice, choice is overwhelmed by happenstance, and/or order does not follow from the choice that is made. And this isn't just on random websites (after all, 90% of everything is crap), but even for core tooling.

Re: The Everything NPM Package

#45

Post by forrestthewoods »

charlie0 wrote: post #17
forrestthewoods wrote: post #12

Earlier quoted context omitted.

That’s a really good way to stagnate imho. I’d rather have 10 sorting libraries that each specialize or make different trade-offs than one library that tries to do everything. That said, you can still have a core set of “blessed” packages that serve the common needs.

I don't see how creating a definitive sorting library is stagnation compared to having 10 mediocre libraries that are all missing some sort of critical functionality.

Your argument seems to be "just write good code instead of bad code". My argument is "the best way for good code to exist is to enable and support multiple options". Because if you have only one option and it's bad then you're screwed with no recourse. C++ and Python have, imho, many horrible API designs and we're stuck with them forever. This is stagnation.

Rust has a good standard library and also a large community of libraries. Sometimes those community libraries get promoted to std because they're strictly better. Sometimes the std version of hashmap is slow because std insists on using a crytographically secure hash when 99.99% of use cases would be better served with a less secure but faster hashing algorithm.

Like many things in life the ideal scenario is a benevolent dictator that only makes good choices. In practice the best way to get something good is to allow for multiple choices.

Re: The Everything NPM Package

#46

Post by Affric »

urbandw311er wrote: post #8
Affric wrote: post #5

What a dissatisfying non-apology of an apology. > First, just want to apologize about any difficulties this package has caused. No rationale. No shame. Just the word “apologize” in a sentence. Who downloaded it though? Surely as a dev if you download such a package it’s on you?

Do you think he should be ashamed? Granted I may have overlooked something, but as far as I can tell it wasn’t an intentionally malicious act, it was a bit of a curious experiment. Seems rather inline with the HN values to me.

Shame is a spectrum. I don’t think he should flagellate himself until the end of time. I think that they should be a little bit embarrassed that they haven’t published what they believed the risk of the everything package was.

Upon rereading the article I can see that the word “unintended” is actually not Patrick’s but the author of the recap’s word.

Beyond that you seem to be ascribing benign intent. Reading it from the horses mouth [1] it doesn’t seems like they had any intent other than trying to find out if it could be done. In a world of worse is better creating the largest possible area of effect for your experiment seems to be a pretty easy way to amp up the consequences of your actions regardless of the risk.

[1] https://uncenter.dev/posts/npm-install-everything/

Re: The Everything NPM Package

#47

Post by Affric »

Retr0id wrote: post #9
Affric wrote: post #5

What a dissatisfying non-apology of an apology. > First, just want to apologize about any difficulties this package has caused. No rationale. No shame. Just the word “apologize” in a sentence. Who downloaded it though? Surely as a dev if you download such a package it’s on you?

He didn't kill someone's puppy, he just published some interesting data that others' code struggled to cope with. He was irresponsible perhaps, but I don't think he foresaw doing any real damage, and I don't think he needs to be especially sorry for it.

I haven’t compared it with killing someone’s puppy. I just think that it would genuinely be helpful to explain a little bit of the rationale and any insight gained from the totally predictable but apparently “unforeseen issues” [1].

It’s the world of worse is better and they’re going for the widest possible area of effect. Should we crucify these guys? 100% not. Part of this is on npm’s design and implementation. Part of it is cultural.

But these guys owe the people who were needlessly “inconvenienced” a little more than just the word “apologize”. Not their first born but some rationale which justifies or reveals that they realise it was a bit pointless or stupid.

[1] https://uncenter.dev/posts/npm-install-everything/

Re: The Everything NPM Package

#49

Post by richbell »

SahAssar wrote: post #38
Bjartr wrote: post #35

Earlier quoted context omitted.

IIRC, the Maven crowd was criticizing npm's decisions from the get go because they chose to ignore many of the problems the Java community already solved a decade before.

So could you list those problems?

Namespaces, for one.

Re: The Everything NPM Package

#50

Post by scubbo »

charcircuit wrote: post #24
nosefurhairdo wrote: post #20

Earlier quoted context omitted.

If you use wildcard to specify any version of a dependency you shouldn't be surprised if something breaks.

The same can be said about not pinning to a specific version as even some patch releases can break things or change performance characteristics.

This, to me, is still one of the most astonishing things about the JavaScript ecosystem that everyone just accepts.
Post reply on HN