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

11–20 of 155 posts

Re: The Everything NPM Package

#11

Post by bsimpson »

troupo wrote: post #3

https://x.com/PatrickJS__/status/1743693931316191671 "accidentally broke NPM and all I got was this sweet permanent banner all over my Github (thats impossible to remove since they probably had to code it up last minute before removing the org/repo)"

GitHub's support is surprisingly bad.

When I was consulting for an R&D lab at eBay, we open sourced a bunch of our work in a GitHub org. It was sanctioned by eBay's OSPO; they even linked to it from their main open source directory.

7 years later, long after the team disbanded, someone in eBay's current legal team decided that the (now archival) org violated eBay's trademarks. For the last year+, every time I've opened GitHub, I've been met with the same undismissable banner.

Since the only choice they give you is to contact support, I did. Unfortunately, their support team is not responsive, and has a completely separate notifications system. It took an inordinately long time for them to respond. (I have poor reception here so I can't check, but I think it was months.) Since I'm not in the habit of checking GitHub Support for new messages, when they eventually replied, I missed it. I had to start a whole new ticket. That too was months ago, and I still haven't heard back.

So because I did some work for a skunkworks eBay team in 2015, the top 150px of my GitHub are unusable, and there's apparently nothing I can do about it until some call center decides to write me back.

Re: The Everything NPM Package

#12

Post by forrestthewoods »

charlie0 wrote: post #10
superasn wrote: post #7

I've seen a lot of people criticise npm and their policies but I've never come across a solution. Npm has its flaws and while there are such abuses like everything package, is-odd, left-pad, etc there are also many useful packages like vue, sortable, etc without which development will be a huge pain. So not asking rhetorically, if we had all the insight and knowledge we have now, how would you make it different?

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.

Re: The Everything NPM Package

#13

Post by TobyTheDog123 »

superasn wrote: post #7

I've seen a lot of people criticise npm and their policies but I've never come across a solution. Npm has its flaws and while there are such abuses like everything package, is-odd, left-pad, etc there are also many useful packages like vue, sortable, etc without which development will be a huge pain. So not asking rhetorically, if we had all the insight and knowledge we have now, how would you make it different?

The entire reason this is a big deal is that people don't know what their dependencies are. The left-pad incident wasn't a big deal because it was pulled, it was a big deal because no one could easily fix their builds and didn't even know they were depending on it, because it was a dependency of a dependency of a dependency.

While it's ridiculous to expect that people will audit every single dependency and sub-dependency, it's not ridiculous to expect tooling to do the same.

Packages should be given an overall quality rating (and honestly it might be great for an ecosystem as large, diverse, and welcoming-to-beginners as JS/TS), part of the score comes from the number of different dependencies/sub-dependencies -- a social package score if you will. If a package causes the dependency graph to explode, give a warning before installing it.

Then, if you're NPM, you don't need all of these convoluted and exploitable policies around un-publishing.

Re: The Everything NPM Package

#15

Post by aaomidi »

superasn wrote: post #7

I've seen a lot of people criticise npm and their policies but I've never come across a solution. Npm has its flaws and while there are such abuses like everything package, is-odd, left-pad, etc there are also many useful packages like vue, sortable, etc without which development will be a huge pain. So not asking rhetorically, if we had all the insight and knowledge we have now, how would you make it different?

Honestly, how go does package management is pretty good.

Re: The Everything NPM Package

#16

Post by aaomidi »

TobyTheDog123 wrote: post #13
superasn wrote: post #7

I've seen a lot of people criticise npm and their policies but I've never come across a solution. Npm has its flaws and while there are such abuses like everything package, is-odd, left-pad, etc there are also many useful packages like vue, sortable, etc without which development will be a huge pain. So not asking rhetorically, if we had all the insight and knowledge we have now, how would you make it different?

The entire reason this is a big deal is that people don't know what their dependencies are. The left-pad incident wasn't a big deal because it was pulled, it was a big deal because no one could easily fix their builds and didn't even know they were depending on it, because it was a dependency of a dependency of a dependency. While it's ridiculous to expect that people will audit every single dependency and sub-depend…

This is why I prefer vendoring dependencies. I have to actually code review them.

Re: The Everything NPM Package

#17

Post by charlie0 »

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 see how creating a definitive sorting library is stagnation compared to having 10 mediocre libraries that are all missing some sort of critical functionality.

Re: The Everything NPM Package

#18

Post by nosefurhairdo »

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.

Re: The Everything NPM Package

#19

Post by ruune »

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?

Re: The Everything NPM Package

#20

Post by nosefurhairdo »

charcircuit wrote: post #4
navtoj wrote: post #2

NPM still hasn't fixed the "*" package version bug on their end. https://www.youtube.com/watch?v=IzqtWTMFv9Y&t=465

It's intentional and is not a bug. "Fixing" it could cause someone's build to break by someone unpublishing a version.

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