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

131–140 of 155 posts

Re: The Everything NPM Package

#131

Post by philipwhiuk »

jonorsi wrote: post #84
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?

Why does he even need to apologize? If anything, npm should apologize and thank him for revealing a huge issue in their unpublishing policies unmaliciously.

I think there's a point when you're trying to do something really stupid and hack around the defences (e.g. rate limits and package JSON file sizes) that it's no longer an accident.

Re: The Everything NPM Package

#132

Post by moritzwarhier »

int_19h wrote: post #109
moritzwarhier wrote: post #64

Earlier quoted context omitted.

There is a trivial way to have custom key comparisons: write a function that returns the key you want. You can implement equals() using some kind of serialization, or using a lookup table of references - whatever you want! Of course, Records and Tuples would greatly simplify the process.

Writing a key comparison function is not a problem. The problem is that Map does not have any way to use such a thing; it always compares using a predefined equality algorithm that is by-reference for all aggregate data types.

I didn't say that you could pass a key comparison function directly into Map.

What I meant was that it's possible to emulate a custom key comparison predicate.

You just have to have a function that returns value for each input that behaves the way you want under strict equality comparison.

Implementing an `equals` function that returns a boolean is more convenient, sure.

Serializing (for plain objects with only JSON-serializable values that would be JSON.stringify) to strings or other primitives would of course be possible with object keys, too. But that's probably what you want for "record"-like objects, right?

And if you want better performance or compare non-primitive values, you'd have to do something more complex, that's what I meant by the lookup table.

But I imagine if you deep-compare large Record objects a lot, the performance wouldn't be any better, because the engine still has to do a deep comparison.

If I am not mistaken, Records/Tuples are in fact strictly limited to this case:

https://github.com/tc39/proposal-record-tuple#jsonstringify

So basically there is no difference to having a function serialize() that just stringifies your plain object, maybe with a caching layer in between (WeakMap?)

OK, thinking about it, the proposal really would help to avoid footgun code where performance optimizations are lacking, and too many deep comparisons or too many serializations are performed.

Re: The Everything NPM Package

#133

Post by SquidJack »

The article is totally misleading there is no storage space running out and system resource exhaustion. btw the total size is around 30MB or less than 50 The only thing is no one can unpublish the npm package because npm have policy if one package is depend on your package you can't unpublish it

Re: The Everything NPM Package

#134

Post by aaomidi »

speedgoose wrote: post #125
aaomidi wrote: post #106

Earlier quoted context omitted.

This is why you should vendor your dependencies. They are part of your codebase at that point.

I have better things to do though. This feels unnecessary.

“go mod vendor”.

That’s it. That’s all you need to do.

Re: The Everything NPM Package

#135

Post by nosefurhairdo »

chatmasta wrote: post #83
charcircuit wrote: post #24

Earlier quoted context omitted.

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

Pinning to a specific version doesn't protect against the author unpublishing that version. The problem with the `*` bug is that it means you can stop anyone from unpublishing future versions of their package by simply creating a package that depends on it with a `*` identifier and publishing that to the registry.

> Pinning to a specific version doesn't protect against the author unpublishing that version.

It does if your project is also in the npm public registry and the package you're dependent on is more than 72 hours old.

https://docs.npmjs.com/policies/unpublish

Re: The Everything NPM Package

#136

Post by jasonjmcghee »

I’m blown away by the reception of this article. It’s wildly low quality, generated SEO spam.

> It was removed, but then reemerged under a different scope with over 33,000 sub-packages. It's like playing whack-a-mole with npm packages!

> This whole saga is more than just a digital prank. It highlights the ongoing challenges in package management within the npm ecosystem. For developers, it's a reminder of the cascading effects of dependencies and the importance of mindful package creation, maintenance, and consumption.

> As we navigate the open source world, incidents like the everything package remind us of the delicate balance between freedom and responsibility in open-source software.

Re: The Everything NPM Package

#138

Post by bandrami »

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 that there's a solution because the fundamental cause of the problem is that Javascript has a huge dev base and everybody wants to have at least one active NPM package they maintain for their resume. Nobody ever asked me as a Perl programmer what CPAN packages I've created because very few Perl programmers made them, but hiring managers will look at Javascript devs' NPM footprint.

Re: The Everything NPM Package

#139

Post by yreg »

yoavm wrote: post #127
yreg wrote: post #118

> The "everything" package, with its 5 sub-packages and thousands of dependencies, has essentially locked down the ability for authors to unpublish their packages. This situation is due to npm's policy shift following the infamous "left-pad" incident in 2016, where a popular package left-pad was removed, grinding development to a halt across much of the developer world. In response, npm tightened its rules around unp…

I guess that's what happens when your whole ecosystem is an afterthought?

But this was a rule that was devised in response to a specific problem in the ecosystem…

Re: The Everything NPM Package

#140

Post by speedgoose »

aaomidi wrote: post #134
speedgoose wrote: post #125

Earlier quoted context omitted.

I have better things to do though. This feels unnecessary.

“go mod vendor”. That’s it. That’s all you need to do.

Oh like this. I’m not sure I would enjoy overloading my git repository and merge requests with the dependencies. I was thinking about having a proxy or forking all the dependencies.
Post reply on HN