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

21–30 of 155 posts

Re: The Everything NPM Package

#21

Post by spion »

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.

A well designed JS standard library that also includes a set of protocols (interfaces) would make such a huge difference in QoL. It would also likely be the biggest contributor to reducing bundle sizes. The protocols (iterable, async iterable etc) will ensure that the rest of the ecosystem can also innovate and participate at a similar level of ergonomics by implementing them

Re: The Everything NPM Package

#22

Post by ruune »

bsimpson wrote: post #11
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 open…

You could probably code up a simple browser extension to hide the banner via CSS if it bothers you a lot. Still only a bad fix that shouldn't be necessary

Re: The Everything NPM Package

#23

Post by jddj »

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.

Right. I'd be very surprised if anyone looks at languages with strong standard libs and says "I wish they had the kind of sorting I can pull in from npm"

Re: The Everything NPM Package

#24

Post by charcircuit »

nosefurhairdo wrote: post #20
charcircuit wrote: post #4

Earlier quoted context omitted.

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.

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

Re: The Everything NPM Package

#25

Post by notnmeyer »

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?

i don’t know how you fix this for js, but in general i think well designed and robust standard libraries are a great place to start.

the community shouldn’t need to write a bunch of tiny utility packages to do common things.

in other words, make it easier to avoid the deeply nested dependency mess that js encourages.

Re: The Everything NPM Package

#26

Post by MetaWhirledPeas »

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.

Because who is going to bother working on any packages if they risk rejection in the end? Have fun with your ______ package because it's never going to improve.

Re: The Everything NPM Package

#27

Post by frabjoused »

NPM as a soulless entity is easy to bash, while the creator of the package is a popular tech influencer so naturally has the support of the masses. If you’re going to complain about NPM, describe how you would solve it in their shoes.

Re: The Everything NPM Package

#28

Post by tentacleuno »

spion wrote: post #21
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.

A well designed JS standard library that also includes a set of protocols (interfaces) would make such a huge difference in QoL. It would also likely be the biggest contributor to reducing bundle sizes. The protocols (iterable, async iterable etc) will ensure that the rest of the ecosystem can also innovate and participate at a similar level of ergonomics by implementing them

> A well designed JS standard library

While I agree here, you also have to remember that additions to the JavaScript standard also increase the amount of time / effort for new browsers to enter the space.

The JavaScript standard (the web APIs, mainly) are already very complex, with Web Workers, Push Notifications, Media Streams, etc. that additions to it should be made cautiously -- once an API is implemented, it's there forever, so the bar for quality is much greater than that of some NPM library.

Re: The Everything NPM Package

#29

Post by o11c »

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?

[flagged]

Re: The Everything NPM Package

#30

Post by sneak »

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.

Golang’s cryptographically verified module proxy cache solves this problem nicely.
Post reply on HN