Live data from Hacker News

Upcoming breaking changes for npm v12

github.blog

121–130 of 221 posts

Re: Upcoming breaking changes for npm v12

#121
post #80
post #56

Earlier quoted context omitted.

Young people thought M$ was changing, the old folks knew it was just another cycle of embrace, extend, extinguish.

Young people were… right? VS Code is open source. (Cursor is built on it!) GitHub didn’t embrace, extend, extinguish git. You can git push to a different company (e.g. Gitlab) and you’ve migrated. The biggest problems with GitHub are scaling and availability, not lock-in. Microsoft today is nothing like it was 30 or 20 years ago. Fifteen years ago we were writing HTML and JavaScript specifically for Internet Explorer…

> VS Code is open source

Open core at best. It's proprietary software built on top of an open source base. The remote coding feature is proprietary and you need to run proprietary software on the remote server / container to use it. People maintaining forks (like Codium and the Theia IDE) are not allowed to use VS Code's marketplace. Many of their flagship VS Code extensions are proprietary. Why would they do this if they believed in open source?

The distinction is quite important. VS Code aims to get control of the development process of those who are not using Visual Studio. That's the only reason why VS Code exists. VS Code is not a gift no strings attached.

By the way the title of https://code.visualstudio.com/ is a lie that says "The open source AI code editor". Three lines under, there's "By using VS Code, you agree to its license and privacy statement.". The license is https://code.visualstudio.com/license, which is very much like your usual horrible Microsoft EULA, including tracking and forbidden reverse engineering, decompiling or disassembling. Really, the only thing missing there is the license key field at first run.

GitHub is still proprietary SaaS also aiming to control the whole open source ecosystem. With GitHub, a big chunk of the open source (and free software! Which is even sadder) world relies on proprietary infra. That's as close as Extinguish as you can get (it's just that git is not the thing that's Extinguished). GitHub is actually a pretty good example of lock-in, see what other commenters wrote on this.

30 years later, Microsoft, still the same lying company trying to control its users and the world with proprietary software. With the twist that they try a bit harder to look cool and open source (since the moment they realized open source wasn't going to disappear, not before). They really are not, especially for end-user facing software, including when the end-users are developers.

The only thing that dramatically changed is that they don't publicly claim Linux is cancer anymore, and that's probably because they are coerced into dealing with Linux. Exactly like the Web against their failed attempt to privatize it with MSN (MicroSoft Network) (the current MSN news frontpage and the memory of their messenger are only shadows of the original ambitions behind MSN).

At least the stability and consistency is comforting… or not.

Don't fall for their open washing. They just play along and attempt to get control on what they didn't manage to extinguish. Only forced changes happened, the spirit seems intact.

Re: Upcoming breaking changes for npm v12

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

Re: Upcoming breaking changes for npm v12

#123
post #5

Looks good? But doesn't this just change the compromise window from first installation to first run?

Yes, but that's actually a huge win. I can't know what a package needs to do at install time - the dev knows that. But I know what my tests and program need to do at runtime because it's my job to understand those things. The dev has to be responsible for ensuring that their build scripts are safe, I need to be responsible for ensuring that my runtime is safe. It'd be great to have more tools for untrusting libraries…

v8 does have a sandbox feature for running untrusted scripts, and it's quite good. There's also Node's VM module.

Re: Upcoming breaking changes for npm v12

#124
post #80
post #56

Earlier quoted context omitted.

Young people thought M$ was changing, the old folks knew it was just another cycle of embrace, extend, extinguish.

Young people were… right? VS Code is open source. (Cursor is built on it!) GitHub didn’t embrace, extend, extinguish git. You can git push to a different company (e.g. Gitlab) and you’ve migrated. The biggest problems with GitHub are scaling and availability, not lock-in. Microsoft today is nothing like it was 30 or 20 years ago. Fifteen years ago we were writing HTML and JavaScript specifically for Internet Explorer…

VScode might be open source (to a degree), but the levers of control are on a different location. See https://ghuntley.com/fracture/ for an excellent blog on it.

Re: Upcoming breaking changes for npm v12

#125

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.

Re: Upcoming breaking changes for npm v12

#126

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.

[dead]

Re: Upcoming breaking changes for npm v12

#127
post #22

> The resulting allowlist is written to package.json Couldn’t this effectively result in the same process we get in pre-12 defaults?

It's unstated, but I'm willing to assume that only the root package.json is consulted to decide if these scripts are allowed. Otherwise, yes, this would not actually change anything.

Thanks for the sanity check!

Had a quick read on my mobile, and that was my first impression.

Guess its more of a way to make the maintainers accountable instead of making npm reputation the main focus.

Re: Upcoming breaking changes for npm v12

#128

npm is basically pnpm now

Except pnpm is written in Rust and is very fast, saves disk and has much more advantage.

> pnpm is written in Rust

Not just yet. The Rust rewrite of the installation engine is still experimental and available as an opt-in preview[0].

[0] https://github.com/pnpm/pnpm/releases/tag/v11.2.2

Re: Upcoming breaking changes for npm v12

#129

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?

[dead]

Re: Upcoming breaking changes for npm v12

#130
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.

Absolutely not, there are plenty of use-cases for them. https://www.npmjs.com/package/patch-package comes to mind off the top of my head.

Hopefully current hysteria will not result in some bs decisions like this.

Post reply on HN