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

141–150 of 155 posts

Re: The Everything NPM Package

#141

Post by theshrike79 »

jasonjmcghee wrote: post #136

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 cascadi…

The "delicate balance between X and Y" is an LLM tic[0]. Especially llama -based language models have a habit of ending any longer piece of text with a phrase like that.

Source: have done a bunch of AI-assisted writing to develop my own skills and the tics and specific turns of phrases really pop out to me.

[0] https://en.wikipedia.org/wiki/Tic

Re: The Everything NPM Package

#142

Post by scubbo »

nosefurhairdo wrote: post #72
scubbo wrote: post #50

Earlier quoted context omitted.

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

Not a big deal, just specify exact dependency versions. Curious how you think other package managers handle this better than npm.

I'm not saying that other package managers handle it better - if authors wilfully misrepresent the state of their software, it is indeed not the remit of the package manager to correct them. If you started down that road, you'd probably end up with a library of tests (executed in the package manager's registry) to guarantee a non-breaking change, and at that point you have to trust the package author that the tests are indeed accurate, which is basically equivalent to trusting them to write the correct `version` string (unless you auto-generate the tests, which is an interesting idea but probably impractical).

I'm saying that the fact that it is (apparently) the norm in JavaScript-world that authors will regularly publish breaking changes that are not advertised as such, and that that is just an acceptable everyday uncommentworthy inconvenience, is surprising to me. How do y'all get anything done if you can't even trust SemVer enough to automatically pull in minor/patch updates to dependencies!?

Re: The Everything NPM Package

#143

Post by scubbo »

Aeolun wrote: post #68
scubbo wrote: post #50

Earlier quoted context omitted.

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

What is your suggestion for improving it? I can accidentally publish a breaking bug in my patch release, and I might not notice.

I believe there is no process or tool that could reliably do so (see sibling comment[0]). Indeed, at some point you need to trust an author that what they are publishing is what they say they are publishing, and authors being fallible means that mistakes _might_ slip by.

What I'm surprised by is the apparent cultural norm that this is just a regular everyday occurrence which entirely erodes any faith in the meaning of SemVer. Sure, we cannot 100% trust SemVer (because humans are fallible) - but there is a world of difference between trusting it ~99.9% and 0%. The JavaScript community (from the outside! I could be wrong!) seems to have simply accepted the 0% situation, and all the extra toil that goes along with it, rather than trying to raise the bar of its contributors to be better.

[0] https://news.ycombinator.com/item?id=38906936

Re: The Everything NPM Package

#144

Post by aaomidi »

speedgoose wrote: post #140
aaomidi wrote: post #134

Earlier quoted context omitted.

“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.

The thing is though that those dependencies are part of your code. Seeing how they're changing through PRs and commits is actually a feature IMHO and not a bug.

Re: The Everything NPM Package

#145

Post by spion »

charcircuit wrote: post #52
spion wrote: post #32

Earlier quoted context omitted.

A softer interpretation is possible. "*" should mean that the dependency cannot unpublish all packages and must have at least one version available.

If someone has an older version in the lock file this will break the build.

Which they can fix by updating the lock file.

Re: The Everything NPM Package

#146

Post by klooney »

rubyissimo wrote: post #117

Does rubygems / go have "protections" against this? Is npm specifically vulnerable to this kind of thing? Or is it just a cultural elelemnt of npm that there are more micro-packages?

Go is a little different here- originally it was totally decentralized, there was no central registry, just URLs. So you could depend on everything, no effect on other packages. No rules on publishing or unpublishing either, because you just get to run your repo the way you want.

At some point, Russ Cox got the Fear about this, and now https://proxy.golang.org/ is an on by default, caching proxy in the middle. You can still delete your packages whenever you want to though.

Re: The Everything NPM Package

#147

Post by bakkoting »

scubbo wrote: post #142
nosefurhairdo wrote: post #72

Earlier quoted context omitted.

Not a big deal, just specify exact dependency versions. Curious how you think other package managers handle this better than npm.

I'm not saying that other package managers handle it better - if authors wilfully misrepresent the state of their software, it is indeed not the remit of the package manager to correct them. If you started down that road, you'd probably end up with a library of tests (executed in the package manager's registry) to guarantee a non-breaking change, and at that point you have to trust the package author that the tests a…

It's not common at all. It can happen, but it's very rare. And it's basically never intentional.

In my experience the most common cause of breaking changes is accidentally breaking on older versions of the runtime, because the project is only running tests on the last version or two. Aside from that, the only notable example I can think of in the last year was a pretty subtle bug in what was supposed to be a pure performance optimization in a query language [1]. I think these are pretty representative, and not meaningfully worse than the experience in other languages.

[1] https://github.com/estools/esquery/pull/138

Re: The Everything NPM Package

#148

Post by zbentley »

theshrike79 wrote: post #141
jasonjmcghee wrote: post #136

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 cascadi…

The "delicate balance between X and Y" is an LLM tic[0]. Especially llama -based language models have a habit of ending any longer piece of text with a phrase like that. Source: have done a bunch of AI-assisted writing to develop my own skills and the tics and specific turns of phrases really pop out to me. [0] https://en.wikipedia.org/wiki/Tic

May well be.

Ironically, the most common place I read the tic of ending a piece of persuasive with a deliberate, unconnected conclusion that doesn't persuade and instead equivocates or states a trivialism ... is in student papers or similarly graded-like-assignments rote work.

Could be that there's a lot of that out there such that it's heavily represented in training data. Could just be a person doing a not-great writing job.

Re: The Everything NPM Package

#150

Post by tentacleuno »

oskarkk wrote: post #39
tentacleuno wrote: post #28

Earlier quoted context omitted.

> 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 t…

If that standard library would be written in JS, a new browser (or rather a new JS engine being a part of the browser) could just use some existing implementation (a reference implementation maybe?), no need to reinvent the wheel in every part of the browser.

> If that standard library would be written in JS, a new browser (or rather a new JS engine being a part of the browser) could just use some existing implementation

That sounds great, but I'm doubtful of the simplicity behind this approach.

If my understanding is correct, v8 has transitioned to C++[0] and Torque[1] code to implement the standard library, as opposed to running hard-coded JavaScript on setting up a new context.

I suspect this decision was made as a performance optimization, as there would obviously be a non-zero cost to parsing arbitrary JavaScript. Therefore, I doubt a JavaScript-based standard library would be an acceptable solution here.

[0]: https://github.com/v8/v8/tree/main/src/runtime [1]: https://v8.dev/docs/torque-builtins -- As I understand it, Torque compiles to C++ at compile-time, which is then linked and compiled into the rest of v8[2]. [2]: https://github.com/v8/v8/blob/main/tools/torque/format-torqu...

Post reply on HN