Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upcoming breaking changes for npm v12

github.blog

Post reply on HN
Print view View original

151–160 of 221 posts

Re: Upcoming breaking changes for npm v12

#151

Post by arcatek »

rozenmd wrote: post #125
partsch wrote: post #107

I wonder if there are still reasons to use yarn? Has yarn also implemented safeguards to protect against supply chain attacks? Until now, I only knew about pnpm. It’s great that npm has followed up.

I worked on a project that used yarn from the early days all the way up to v3, it's slow as hell, but it works. They also have the supply chain protections. Eventually we snapped and migrated to pnpm. Installs (both in CI and on local dev machines) are significantly faster. Turned out to be about a day's work to migrate with an LLM's help.

I don't doubt that 3.x probably has worst perfs (it's almost two years old now), but just to clarify we closely track performances and Yarn and pnpm and pretty much on similar level:

https://p.datadoghq.eu/sb/d2wdprp9uki7gfks-c562c42f4dfd0ade4...

Re: Upcoming breaking changes for npm v12

#152

Post by port11 »

Eji1700 wrote: post #93
tuckwat wrote: post #46

I bet there have been a hundred different discussions about this inside of NPM since it was disclosed 10 years ago. With Shai Halud it's gotten too big to ignore.

I do love that javascript's history is basically just coder mentality distilled. "oh yeah we'll fix that shortly" is almost always "oh fuck now we have to"

I chuckled, but this is more about the history of NPM.

In retrospect, allowing an ES consortium seat (Microsoft) to own the largest package repo for the language… might have been a bad idea? Google is one of the worst members of the language board, but Microsoft might be a close second.

Given their ownership of GitHub came with a general community unease, perhaps it’s not surprising that NPM isn’t dating much better. 16 years later we are getting good security controls. Okay.

I’m happy with Deno for most of my needs!

Re: Upcoming breaking changes for npm v12

#153

Post by port11 »

gear54rus wrote: post #134
philipwhiuk wrote: post #131

Earlier quoted context omitted.

The entire use-case of that package is a security nightmare.

Then don't use it. Just don't presume to tell me if I can or can't.

You’re free to allow scripts as per the linked docs for NPM 12. But the vast majority of us will appreciate the reduced attack surface.

Re: Upcoming breaking changes for npm v12

#154

Post by creesch »

amitport wrote: post #69
joeyhage wrote: post #3

Earlier quoted context omitted.

Most people know this but the _real_ reason it explains things is that GitHub is owned by Microsoft. Oh, and Microsoft moved GitHub to Azure

To be fair, NPM sucked long before it got acquired by Github/Microsoft. And to be fair 2: The other package repos also suck.

> And to be fair 2: The other package repos also suck.

If you mean other languages, then yeah a lot of similar issues and weirdness there as well. Maven dependencies in any complex project are a "fun" challenge as well.

Though the sort of recurring supply chain attacks you see within the npm ecosystem is something I haven't seen elsewhere to this degree.

Re: Upcoming breaking changes for npm v12

#155

Post by z3t4 »

tobyhinloopen wrote: post #147
z3t4 wrote: post #144

npmjs.org is a joke at this point. I guess their support is run by LLM because you can just write to them and they will transfer ownership of any module nilly willy.

That’s a bold claim to randomly write without any supporting sources

I've got an example and submitted it via bug bounty channel, but they classified it as "social engineering".

Re: Upcoming breaking changes for npm v12

#156

Post by VMG »

atraac wrote: post #122

postinstall scripts should've been removed long time ago, it's the cancer of NPM packages. There's so many deeply nested, uncontrolled postinstalls that run randomly when you pull something it's insane, I don't know how someone at some point ever though that was a good idea.

I must admit I don't really understand what the point of the post-install script concern is.

Usually, you run the actual packaged dependency code at some point anyway, and usually with the same permissions as the install process.

So all of these setup scripts (good or bad) can just move their entrypoint from npm to wherever the `import` or `require` happens.

It seems to me that this is a small stumbling block at best, unless the whole ecosystem moves to a deno-like sandboxed environment. Maybe that is the plan?

Re: Upcoming breaking changes for npm v12

#157

Post by 7bit »

dust-jacket wrote: post #142
7bit wrote: post #106

Earlier quoted context omitted.

Was that the case? Can you provide sources to your claims and provide a foundation to your theories?

https://www.theregister.com/software/2019/04/01/nice-people-... Year before the MSFT takeover. No idea about their actual financials but they were definitely shedding headcount pre 2020, including kicking people for trying to unionise.

Nothing in there suggests that this was done to save the company from bankruptcy, which was the wild claim.

Re: Upcoming breaking changes for npm v12

#158

Post by 7bit »

tomnipotent wrote: post #111
7bit wrote: post #106

Earlier quoted context omitted.

Was that the case? Can you provide sources to your claims and provide a foundation to your theories?

It's literally a Google search away. If you had the time to write this comment, you had more than enough time to do the search.

Not my job to proof the wild claim that the layoffs were to save the company from bankruptcy .

Re: Upcoming breaking changes for npm v12

#159

Post by tuwtuwtuwtuw »

arcatek wrote: post #148
partsch wrote: post #107

I wonder if there are still reasons to use yarn? Has yarn also implemented safeguards to protect against supply chain attacks? Until now, I only knew about pnpm. It’s great that npm has followed up.

Of course. Modern Yarn releases (4.x) are deterministic to a fault and you can rely on it to have a consistent behavior across your whole team. As for feature-wise I'd say it's a lot of small details that together add up once you grow used to them. The next major release will keep pushing in that direction with both better performances and features we couldn't implement until now due to their reliance on said perfs i…

Deterministic to a fault unless you mix Windows and Linux.

https://github.com/yarnpkg/berry/issues/6105

Re: Upcoming breaking changes for npm v12

#160

Post by tuwtuwtuwtuw »

doctorpangloss wrote: post #47
therealmarv wrote: post #42

Earlier quoted context omitted.

As if supply chain attacks could have been prevented by 2fa or passkeys always. You want delays by x days because supply chain attacks get caught very often within 1-2 days. And if you really really want to make an exception for a zero day then that's no problem and you can still quick patch by exclusion of that rule. They don't contradict in a unsolvable problem. You want both, you get both.

How do you know what's a zero day fix? (You write something) So then you have to check every package's updates and decide if you update, yes?

Yes, you need to check security issues reported for packages and then take a decision. What is the alternative?
Post reply on HN