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

121–130 of 155 posts

Re: The Everything NPM Package

#121

Post by baz00 »

ironmagma wrote: post #85
baz00 wrote: post #54

Earlier quoted context omitted.

Personally I would like it and the ecosystem to just cease to exist overnight. Nothing on earth has caused so much pain, misery, suffering and agony, apart from possibly PHP. Our devops guys scream from the seething pain whenever the have to debug some pile of shit that decides it won't build unless all the runes are aligned precisely and all the RAM in the universe is available on the build runners. And pushing this…

I'm sorry, but there is no chance that the automake/autoconf suite of tools has caused less pain than `npm install`.

We have almost buried those.

Re: The Everything NPM Package

#122

Post by cxr »

aaomidi wrote: post #16
TobyTheDog123 wrote: post #13

Earlier quoted context omitted.

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.

Whether you're storing your own copy of a given dependency and whether you've done code review for it are orthogonal concepts. (You can check it in and perform the same amount of review that people do when deferring to `npm install` for late fetching, i.e. none.)

Conflating these two not-unrelated-but-still-distinct concepts is a big contributor to why the current state of the art is so fraught.

Re: The Everything NPM Package

#123

Post by sakjur »

quickthrower2 wrote: post #114
sakjur wrote: post #110

Earlier quoted context omitted.

Wouldn’t the opposite be better? I’m not sure you could take advantage of the vast majority of files in the zip files being unchanged if you kept compressed archives.

Not sure what you mean but typically you don’t need to track changes of libraries to that level. At least not in the context of a repo using those libraries. I am thinking of treating them like binary .dlls.

Source control is really good at compressing text files as they evolve over time, but isn’t optimized to handle binary assets. Since a single-line patch changes the entire zip archive, you’d risk growing the size of the repository based on the number of patches.

Re: The Everything NPM Package

#124

Post by happens »

Most articles say the page includes a Skyrim meme, but no one says what the meme is and I can't find anything relating to Skyrim on everything.npm.lol. This is very confusing to me.

Re: The Everything NPM Package

#125

Post by speedgoose »

aaomidi wrote: post #106
speedgoose wrote: post #97

Earlier quoted context omitted.

It's personal tastes perhaps, but I don't find the appeal of packages management in Golang. I find PIP, NPM, RubyGems, Nuget, Cargo,… easier to work with. The go.mod syntax is what it is, and doing updates or fixing conflicts isn't easy. Not having a registry is neat, but I'm also unsure of what is going to happen over time as dependencies may be moved or removed. You can see that with old Maven pom.xml where some de…

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.

Re: The Everything NPM Package

#126

Post by speedgoose »

mseepgood wrote: post #115
speedgoose wrote: post #97

Earlier quoted context omitted.

It's personal tastes perhaps, but I don't find the appeal of packages management in Golang. I find PIP, NPM, RubyGems, Nuget, Cargo,… easier to work with. The go.mod syntax is what it is, and doing updates or fixing conflicts isn't easy. Not having a registry is neat, but I'm also unsure of what is going to happen over time as dependencies may be moved or removed. You can see that with old Maven pom.xml where some de…

> I'm also unsure of what is going to happen over time as dependencies may be moved or removed That's what the Go module proxy is for. The authors can move or remove their repositories as much as they want, I as a dependent am not bothered by it. They would have to go through an official vetted process to get it removed from the proxy.

Oh I didn’t know that the proxy.golang.org was a thing. That’s good to know.

Re: The Everything NPM Package

#127

Post by yoavm »

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?

Re: The Everything NPM Package

#128

Post by tentacleuno »

spion wrote: post #36
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…

A JS standard library would be a drop in the bucket compared to the size and complexity of the DOM libraries and implementing a usably performant JS engine. Yes it should be done carefully. There are also plenty of examples of how this can be done well, done by experienced engineers. For example, the Dart starndard library ( https://dart.dev/libraries - core [1], collection [2] and async [3] in particular) is a very…

> A JS standard library would be a drop in the bucket compared to the size and complexity of the DOM libraries and implementing a usably performant JS engine.

It's still a nonzero amount of complexity. I see a lot of "v8 is really hard to compete with" comments on here so this feels very pertinent to mention. You can't have it both ways.

> Yes it should be done carefully. There are also plenty of examples of how this can be done well, done by experienced engineers. For example, the Dart starndard library (https://dart.dev/libraries - core [1], collection [2] and async [3] in particular) is a very good model that would fit JS fairly well too (with some tweaks and removals) > > [1]: https://api.dart.dev/stable/3.2.4/dart-core/dart-core-librar...

This one, at least, looks somewhat inspired by JavaScript.

Re: The Everything NPM Package

#129

Post by tentacleuno »

abacadaba wrote: post #99
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…

Hasn't everyone pretty much given up on making a new (standards compliant) browsers after Microsoft gave up? (Or are they still trying to make Servo viable?)

> Hasn't everyone pretty much given up on making a new (standards compliant) browsers after Microsoft gave up?

There's plenty of competition, even if the current projects are in a beta (or even alpha) state. Consider the LadyBird browser developed by SerenityOS, or Servo.

Re: The Everything NPM Package

#130

Post by philipwhiuk »

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)"

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.
Post reply on HN