Upcoming breaking changes for npm v12

https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/

by plasma • 1 month ago

484 206 1 month ago

didn't know npm was owned by github.. well, that explains things...

joeyhage• 1 month ago

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

amitport• 1 month ago

To be fair, NPM sucked long before it got acquired by Github/Microsoft.

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

BowBun• 1 month ago

yes, since 2020

shagie• 1 month ago

NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (March 16, 2020; 571 comments; 1829 points) - https://github.blog/news-insights/company-news/npm-is-joinin...

Some of it aged... interesting.

Top comment:

Microsoft doesn’t do everything right but the GitHub acquisition has honestly gone better than I ever expected. Rather than forcing GitHub to adopt Microsoft centric policies, Microsoft has adopted more GitHub stuff, especially from a product POV. GitHub still runs as a separate company (different logins and health care and hiring systems) with its own policies and point of view.
...

w29UiIm2Xz• 1 month ago

To be fair, the vibes (at the time) were that Microsoft has changed. Probably, in some way, a zero-interest rate phenomena.

shimman5• 1 month ago

MSFT acquisition of NPM was a massive shit show, they fired many staff engineers and people that were at github for quite a while. Top comment was a liar.

altmanaltman2• 1 month ago

it was all good until AI entered the chat

ralph84• 1 month ago

NPM (the company) was about to go under in 2020. They raised VC but never found a sustainable business model. GitHub acquired them to keep the ecosystem alive. The acquisition hasn't really benefitted GitHub much at all.

materielle• 1 month ago

I don’t know if this is the case here, but it’s very hard in general to judge how much software projects ought to cost.

Software projects will grow in complexity to consume whatever budget you give it. If you hire 50 devs and give them a bunch of business objectives, they are going to do what they do and write a ton of software.

It’s not obvious to me that it would be theoretically impossible to build a cheaper package manager.

hinkley9• 1 month ago

No there are gobs of node projects on GitHub. I'm sure someone did the math on how many paying customers would have been fucked if npm.org went away and it worked as a loss leader.

domh• 1 month ago

I knew it was owned by github, but this is the first time I've personally seen the release notes on github's blog instead of npm's.

Tiberium• 1 month ago

I hope GitHub changes their vibecoded badges, what does RETIRED even signify in this context? Why does the preview have to be in ominous red?

mort963• 1 month ago

Hahaha that's amazing, just a big red "RETIRED" badge above their blog post? What the hell

petetnt• 1 month ago

Breaking changes have had that tag for ages

sheept• 1 month ago

The changelog design has been like that since last year,[0] which predates today's slop design of small caps and monospace text (probably because they both are based on the same design trend). A year ago, vibe coded websites leaned more on sans serif and gradient text.

[0] https://github.blog/changelog/2025-05-05-improvements-to-cha...

TZubiri4• 1 month ago

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

christophilus• 1 month ago

Better than nothing. That’s the same problem every package manager has.

semiquaver• 1 month ago

Ok? Not sure what a package manager can do about the fact that eventually you want to run the things you install.

frabcus2• 1 month ago

Have any kind of provenance. eg like Debian has for 30 years. Key signing in person etc

Someone1234• 1 month ago

I’m sure we’d all welcome your alternative and or superior proposals.

Without that, this just comes across like unconstructive commentary.

This moves the needle a little your proposals or the lack thereof don’t move it at all. So I’ll take this over nothing.

mschuster91• 1 month ago

An idea might be to not just pin "package xyz allowed", but "package xyz postinstall allowed with hash <1234>".

spartanatreyu2• 1 month ago

We already have alternative and superior proposals, it's called Deno.

It's node + npm compatible and its permission system locks everything down by default.

If you know ahead of time, you can turn on which permissions something is supposed to have in the config file.

Or you can just not use a config file at all. Anytime it needs a permission: it asks you what it wants. You can say yes or no, and those are saved in the config file for next time. If you say no, the script throws an error where it tried to access something it didn't have permission for.

---

Example:

- My linter wants access to my file system?

  - You can have read access to ./src/ts/

- My bundler wants read and write access to my file system?

  - You can have read access to ./src/ts and write access to ./build-output

  - Huh, what's that? The bundler was trying to both read and write a file in ./src/ts?

  - We don't want input files getting overwritten, that's a recipe for hard-to-diagnose race conditions. Looks like the permission system did more than just keep things secure, it's like a type system for IO.

  - Oh, look at that, there was a very subtle bundler misconfig, let me fix that now. How long would that have existed if we didn't use deno...

- Oh what's this? An updated dependency I've been using for 6 months suddenly asking for access to my .env file, and asking to run curl in a separate process? How about "no". Why would a simple DOM utility dependency be asking for those permissions? Ah, looks like it was part of a credential stealing supply chain attack. Glad I wasn't using node.

---

Addendum: Node now has a permission system, but it's broken by design so it's useless.

TZubiri4• 1 month ago

You'll notice that my comment was a question, you can tell by the presence of question marks at the end of the sentence.

Additionally, if a comment were to hypothetically point out an issue, that is valuable on its own. If someone reacts to a comment that points out an issue this defensively, it's a huge red flag.

grassfedgeek• 1 month ago

"First run" doesn't exist for JavaScript libs used only in web apps. So for that entire class of packages this change makes them safe.

tabwidth• 1 month ago

Build tooling still runs though. Your bundler plugin or PostCSS transform gets full fs access at build time, nobody's auditing that.

WatchDog• 1 month ago

"First run" certainly exists in web apps, it's just running JS in a browser rather than a shell script on a developer or CI machine.

There is plenty of malicious stuff you can do from the browser.

TZubiri4• 1 month ago

But this is npm, the execution environment is not the browser, but the server.

Most packages are imported via import/require, even if it's a browser only package. Because of SSR and reasons.

Or maybe not, let's look at a random browser only example, angular and react will use SSR, so they will execute in the server, let's check Jquery:

https://www.npmjs.com/package/jquery

Docs suggest just using a script tag instead of npm, when using npm install, they suggest to run import statement, which can execute arbitrary code.

The bottom line seems to be that if you are using npm, it's cause you are using node, and therefore you will run the imported code in the server, otherwise you would use a script tag.

But maybe there's a way to define a browser only package or .js URL such that it is only downloaded and served but never executed server side?

In any case, not a huge usecase of npm, which again, is designed for node which is backend.

Randome example,

include

Rohansi• 1 month ago

Don't forget about tests. That'll run code for every package that is imported. Yes, imported, because in JS importing means "run all the top level code in this file". So to continue exploiting you just place your malicious code in index.js instead of a postinstall script. Not as guaranteed to run but still very likely.

pjio• 1 month ago

So for that entire class of packages this change makes them safe.

This is misleading. The change addresses one important attack vector. But if one runs the application directly on the host for development, if the package is imported like pointed out in the other comments or the package intends to steal user credentials from production, it is far from "being safe". Safer, but still needs scrutiny.

insanitybit• 1 month ago

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 (iframes are awesome for this on the frontend) but this is still a massive win.

tentacleuno• 1 month ago

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

cute_boi2• 1 month ago

They should have added a 1-day age limit by default, so security scanners have some time.

KolmogorovComp• 1 month ago

I don't think it'd necessarily be a good decision, sometimes CVE are actively exploited and need quick patching.

A better safety net would be to require active 2FA proof for every package update.

jnwatson• 1 month ago

If you need a quick patch, you pass another parameter to turn off the 1 day. 1 day delay will prevent more problems than it makes.

therealmarv2• 1 month ago

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.

woodruffw2• 1 month ago

I think you want both of these things. Realistically we're not at a point yet where all MFA credentials are phishing resistant.

hedora2• 1 month ago

“How do I get my security hardened CD pipeline to 2FA?”

geophph• 1 month ago

The maintainer of pnpm mentioned this on the pod rocket podcast recently. Based on recent npm exploits they decided to (and based on a poll they did most users agreed) set to 1 day by default in v11. Can always choose to change it if you desire.

frabcus2• 1 month ago

LLMs are reducing n-day exploit time rapidly.

https://red.anthropic.com/2026/n-days/

So that is a poor bandaid to use now. Maybe instead validate things before, and have more of a cathedral and human reputation system.

hinkley9• 1 month ago

I would have been fine with 24 hours but some of my co-maintainers asked for longer.

Which was a little weird for the modules that don't run standalone but whatever.

efortis• 1 month ago

this release fixes a vulnerability reported 10 years ago

https://www.kb.cert.org/vuls/id/319816

ares623• 1 month ago

Breaking: AI fixes 10 year old vulnerability!

Zopieux• 1 month ago

Eh, that only took a few dozen actively exploited supply-chain vulns in the span of two years!

dawnerd• 1 month ago

Only took Microsoft themselves getting hit with it for things to change.

punkbit2• 1 month ago

The resulting allowlist is written to package.json

Couldn’t this effectively result in the same process we get in pre-12 defaults?

CGamesPlay• 1 month ago

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.

punkbit2• 1 month ago

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.

karakanb• 1 month ago

It is not obvious from the post but it seems like the allow list for the scripts supports whitelisting packages instead of a global setting. This should make it easier to maintain org-wise rules to allow scripts only for specific packages.

Is there a linter that could be used for scenarios like this to prevent unsafe default on package manager config?

philipwhiuk3• 1 month ago

grep?

ComputerGuru• 1 month ago

My big question as an OSS dev distributing some precompiled binaries via npm for easy installation: does allowScripts also default to disabled when directly installing a package (globally or otherwise)?

jamiem3• 1 month ago

Yes, all install scripts will be disabled by default regardless of if they are from direct or transitive dependencies.

But if you're already following the os + cpu + optionalDependencies model to distribute your precompiled binaries you should be fine.

themafia• 1 month ago

The "aw geez, enough is enough" release.

Finally.

thatmf• 1 month ago

allowScripts defaults to off

Nice that they're following pnpm's lead on this after [checks watch]... 18 months?

MrBuddyCasino2• 1 month ago

Java‘s Maven never had them, never felt a need for them.

What is their purpose in JS land?

dgoldstein0• 1 month ago

Off the top of my head the purposes I've seen for them: - building native bindings (node-sass) - asking for funding (core-js)

... Probably a few more but the native case is probably the biggest and the packages I'm using nowadays ship precompiled blobs in optionalDependencies. Install scripts seem to be out of favor.

tuananh3• 1 month ago

native modules. nodejs can have native modules (written in C++, Rust, etc...). Projects usually ship prebuilt natives binaries (for each arch/OS/Nodejs ABI combination) hosted on GitHub Releases and download them automatically at installation time; fallback to build from source if not found. that's where scripts are used

the reason for not bundling all native binaries is becasue the no. of combinations are huge and it can make module size hundreds of MBs

inigyou4• 1 month ago

Maven has plugins which are downloadable modules that run at install time, IIRC?

tuckwat• 1 month ago

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.

appplication• 1 month ago

Great, now it’s python’s turn next

Eji1700• 1 month ago

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"

port112• 1 month ago

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!

the8472• 1 month ago

A different framing would be things moving from a high-trust equilibrium to a low-trust one due to a few bad actors and no other way to stop their activities.

Security part reasonable code robustness, part Red Queen's race. Attackers expend ongoing effort for new exploits, defenders expend ongoing effort to get back into a secure place, everyone ending up where they started.

If world were a nicer place we wouldn't have to "fix that shortly".

retardedsecguy• 1 month ago

npm is basically pnpm now

cute_boi2• 1 month ago

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

uasi• 1 month ago

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

Pxtl• 1 month ago

I would've assumed lockfile-by-default. We're still going with auto-updating?

jbreckmckye• 1 month ago

You do get a lockfile by default

zarzavat• 1 month ago

There's an easy way to stop most supply chain attacks:

1. Publishing users must approve each and every release from a smartphone app.

2. Publishing users must provide verified government ID.

The first step prevents the types of attacks where an attacker gets control of a maintainer's computer and publishes a new release.

The second step discourages attacks where a user tries to get a malicious package used by others.

When combined with the security features that already exist, e.g. delays and automatic scanning, it would make it considerably harder to pull off a successful attack.

ifwinterco• 1 month ago

Issue is this is such a pain (and shuts out a large percentage of the world population) that you'll inevitably get a parallel ecosystem of packages without these onerous controls that everyone would end up using.

I don't know how to square the circle but any variation of "make it safer but really painful and difficult for anyone to publish a package" has this problem

inigyou4• 1 month ago

How would this prevent Shai Halud?

hinkley9• 1 month ago

No, because we've already had documented cases of people socially engineering exploits into OSS projects.

You don't need permission to publish an exploit, you just need someone or something else to do it for you.

SCLeo2• 1 month ago

I don't get it. How does this help with anything? You pull in a dependency to use it, right?

dlopes7• 1 month ago

Well pulling some code is different than running a script on your machine

SCLeo2• 1 month ago

Frequency of actions matter, especially for security changes. If we are talking about git, I agree. If we are talking about npm, I bet 95%+ times people install packages in order to use them, not just to admire the code.

Someone else in this thread mentioned that npm can be used to manage pure front end libraries, which is a fair point.

thrdbndndn• 1 month ago

How do you allow scripts for tools installed globally?

jamiem3• 1 month ago

Either pass the --allow-scripts=<pkg> flag with npx or npm install -g, or set allow-scripts=<pkg> in .npmrc

beart• 1 month ago

Does the allow list in package.json pin to the package version, or only to the package name?

cookiengineer2• 1 month ago

What a pointless change.

If you force every user to just use "--enable-unsecure-feature", guess what will happen?

This is not about improving security. This is about shifting blame.

A much better alternative would've been the introduction of sandboxes or simulation runs that would output which scripts and programs are running due to unpredictable dependencies. This way the user could check before the actual execution, and maintain an allow list much easier. That could be done via an npm update && npm upgrade workflow where the update generates the list that the user has to manually confirm.

Heck, even a chroot would be an improvement, and they're almost pointless these days, considering how good malware got at escaping chroots.

woodruffw2• 1 month ago

I don't think it's pointless. A large number (the majority?) of users probably don't need install scripts, so disabling them by default is a net security improvement. Those that do can enable the insecure behavior, which will become an explicit decision that is trackable, auditable, etc.

You're not wrong about sandboxing, but sandboxing isn't something that can just be blithely introduced to a large packaging ecosystem that previously assumed full system access. Doing so results in the same kind of regression you point out: if the sandboxing breaks peoples' builds, they'll just disable it and move on with their goals.

garbagepatch• 1 month ago

Most users don't need it. Having it on by default is a feature for malware writers not users.

But to your point, Node has had permission flags for a while[0] but allows everything by default. Npm could use them to increase security even more. I just hope it doesn't take them another 10 years to change the default.

[0] https://nodejs.org/api/permissions.html

hedora2• 1 month ago

Most packages don’t need it, but I imagine a large percentage of users do since most projects pull in an insane number of packages.

Still, “default off” is better. It would be nice if there were a lightweight way to fork upstream packages, and cache the native builds. It’d improve build times, make the build step more explicit / sandboxable and allow for easier binary builds for operating systems and processors that M$ treats as second class.

recursive• 1 month ago

I'm not going to get forced.

imtringued• 1 month ago

This is kind of like arguing that immutable by default variables are pointless.

If you force every user to just write "mut", guess what will happen?

They will write "mut" when they need mutable variables, which in practice turns out to be the minority of variables.

It's the same with "Option". The vast majority of variables or struct members do not need to be nullable at all.

cookiengineer2• 1 month ago

If you force every user to just write "mut", guess what will happen?

This is the wrong analogy.

The equivalent analogy would be using a compiler flag that is triggered for all dependencies and all included libraries without a per-library or per-file changeability. Something like "gcc --force-mut-all-yolo".

Variables have scopes of concern. This new NPM feature has no scope. And that's what my critique is about, because it makes it still unpredictable if any of your dependencies of dependencies needs a script.

The spread vector of potential malware stays identical, because the reason the miasma worm is spreading so fast is because of dependencies of dependencies that are impossible to audit on a case-by-case basis, given the lack of sandboxes and the lack of allowlisting scripts on a per-dep-and-version basis.

inigyou4• 1 month ago

This is pip with --break-system-packages heh

jbverschoor2• 1 month ago

And when will we get rid of the vendored node_modules, and make it read only?

alexghr• 1 month ago

Are the current LTS node versions (iirc 22, 24, 26) going to update the bundled npm to v12 to benefit from these security fixes? All come with npm v11 now

jamiem3• 1 month ago

Major npm version bumps have landed mid-stream for node in the past: v18.19.0[1] and v20.10.0[2] bumped npm 9 to 10.

[1] https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v... [2]: https://nodejs.org/en/blog/release/v20.10.0

b1122• 1 month ago

They are changes in defaults, which could be construed as a security posture change, but the security fix is in everyone's hands. Just set proper defaults, as per article, and done.

I think the best part of this change, is that the default change will mean that lots of new DEVs just running an install, will see instant breakage with annoying packages that presume these settings are on. It should force people to stop expecting scripts to be runnable, for example.

partsch2• 1 month ago

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.

partsch2• 1 month ago

To the people downvoting my comment: Feel free to answer my question. I really don't know the answer.

rozenmd• 1 month ago

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.

arcatek5• 1 month ago

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

homebrewer2• 1 month ago

One distinguishing feature is their optional install strategy: running packages directly from compressed archives instead of unpacking them into node_modules.

https://yarnpkg.com/features/pnp

Very similar to using .jar's in Java instead of directory trees of .class files.

It's somewhat hacky though, and editor/tool support varies.

- since there are far fewer small files, it can be faster especially on Windows if you're forced to work on it for some reason

- the archives can be stored into the git repository (through git-lfs or friends), removing dependency on the internet and the package registry

arcatek5• 1 month ago

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

Disclaimer: I'm the Yarn lead maintainer.

tuwtuwtuwtuw3• 1 month ago

Deterministic to a fault unless you mix Windows and Linux.

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

mkesper• 1 month ago

It was a giant mistake to keep 'classic' (umnaintained, unpatched) yarn around. Switched to pnpm in part due to that reason.

Zanfa• 1 month ago

I don't know what NPM is doing, but yarn installs deps much faster than NPM

reddalo• 1 month ago

I feel like Bun is even faster than yarn, but I'm afraid to keep using Bun since they made AI rewrite it completely in another language

Timon32• 1 month ago

Though I mostly use pnpm these days, yarn still has a feature that I frequently miss: the project-local cache[0]. Basically, every dependency archive fetched from a registry is stored in your repo in .yarn/cache, so unless you're adding/updating dependencies a `yarn install` will work fully offline.

I'm sure there are drawbacks to this method regarding repo size etc., but it just feels good knowing that my repo contains everything needed to install and run any version of my project.

[0] https://yarnpkg.com/features/caching#offline-mirror

Timon32• 1 month ago

I should add: this is enabled by adding `enableGlobalCache: false` to .yarnrc.yml, though I think it was the default for a bit when Yarn 2 first released.

peterkelly• 1 month ago

Now all the malware can move from the install script to the module itself where it will inevitably still be run

hinkley9• 1 month ago

But at least we have ways now to stay a week behind everyone else and see how many people drop dead before us.

So what it'll really be is people injecting exploits that are patient.

chimpanzee2• 1 month ago

Cool, but I default to pnpm these days anyway.

atraac2• 1 month ago

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.

gear54rus2• 1 month ago

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.

philipwhiuk3• 1 month ago

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

homebrewer2• 1 month ago

Your own link says that a proper package manager (e.g. pnpm) supports this out of the box.

If there are other use cases that really need post-install scripts, you can whitelist just those in pnpm. In projects I'm working with, there are often zero post-install scripts that must be enabled for everything to work properly, and it's usually from poorly cobbled packages that use them to download prebuilt binaries (well written packages, like biome or tsgo, use per-architecture subpackages).

You enable just one or two of those, and block everything else.

atraac2• 1 month ago

How would getting rid of postinstall break patch-package? If people use a package, and that package needs some kind of step to get working, user of that package should decide when that step happens. He can very well just call patch before building on his own. There's zero issues with that approach and the upside is he actually has control.

I work in a monorepo where running install calls dozens of deeply nested postinstalls of some elaborate NextJs or React Native dependencies other projects use. It's borderline insane. Unless you regularly screen everything, it's impossible to know whether one of those is compromised, especially in the world of Node where is-even is being used and the sheer amount of crypto scams around.

VMG• 1 month ago

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?

vbezhenar• 1 month ago

You can build application outside of container, but run it in container. I think that it is simpler workflow, than everything in container (when you actually need to develop it with IDE).

I didn't try devcontainers stuff, TBH. But that's how I often develop my apps.

That said, there are other attack surfaces for that approach. For example I'm not sure if I can trust LSP server not to execute application code. So keeping everything in a container or in a VM seems to be the only sane approach to work with code you don't trust.

jeremyjh2• 1 month ago

A lot of packages are only used in the browser; if you don't use SSR they'd only be executed by node in unit tests in something like jest, but that is not the only way to run unit tests (Cypress can run them in a headless browser [1], for example). Running those sand-boxed would be the next logical step.

Removing automated execution of postinstall is a necessary step and may as well be the first one.

[1] https://docs.cypress.io/app/component-testing/get-started?ut...

padjo• 1 month ago

If you only use npm to manage client side deps then it removes the ability to compromise a devs machine or the CI server. Seems like nice attack vectors to just eliminate entirely.

re-thc• 1 month ago

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

That would / could kill performance

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

So I doubt most people trace every dependency they install all the way. So sometimes it comes upstream. Maybe you don't run it. It could have been a dev dependency accidentally set for runtime and now you have it.

stefan_• 1 month ago

If you want to build a modern web frontend you will need to use npm. But a lot of those only ever run in the users browser where they can't do any harm. I would never consider the insanity of that ecosystem for backend work.

hinkley9• 1 month ago

On a project with a 1GB node_modules directory (after aggressive cleanup) I think we only had one dependency that didn't work right with postinstall disabled. Though I can't recall which and I don't work there anymore so I can't hunt.

And IIRC that one was fixable by a PR, because they'd done something weird and there was an idiomatic way to accomplish the same thing.

philipwhiuk3• 1 month ago

On balance, it’s npm’s belief that the utility of having installation scripts is greater than the risk of worms. This is a tradeoff that we will continue to evaluate.

They chose...poorly

z3t42• 1 month ago

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.

tobyhinloopen• 1 month ago

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

z3t42• 1 month ago

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

bastawhiz• 1 month ago

I'm not sure how I missed that npm was acquired by GitHub, but man, a lot of stuff suddenly makes a lot of sense. I really can't think of a worse home for such a critical part of the Node ecosystem.

flexagoon• 1 month ago

Happened in 2020 apparently

https://github.blog/news-insights/company-news/npm-is-joinin...

beardsciences• 1 month ago

I literally said "Oh, of course" out loud.

afavour• 1 month ago

Eh, it was pretty terrible before the acquisition too...

hinkley9• 1 month ago

It's way less shitty now. Though one could kill a couple beers just complaining about how many major node versions it took before it wasn't shitty.

classified• 1 month ago

Strategical positioning for enshittification, control and future squeezing of profits. Embrace, Extend, Extinguish.

https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

sneak2• 1 month ago

I don't think Microsoft is trying to extend and extinguish javascript or typescript. I do, however, think they are using their standard anticompetitive playbook to disadvantage IDEs that aren't VS Code and agents that aren't Copilot.

For example, it requires some hackery to use your Copilot subscription via the Copilot extension in VSCodium (the f/oss distribution).

They want the default to be writing javascript (where the default is npm), written in VS Code, publishing to GitHub. You can already see NPC devs mindlessly following this pattern.

The response is to refuse to use Microsoft software. Use a Mac, don't use Excel or Word, don't use VS Code. I've also pulled my repos from GitHub and won't publish there or on npm. Their ecosystem makes the world worse, even before you factor in the fact that they happily provide services to ICE to aid them in running concentration camps.

hinkley9• 1 month ago

As someone who used npm since at least 2014, it was already fucked before Microsoft (who owns GitHub) got there to make things worse. That's why yarn and pnpm and bun and a few lesser knowns exist.

butz• 1 month ago

Better late than never.

WhyNotHugo• 1 month ago

To see what would be blocked, run npm approve-scripts --allow-scripts-pending

This naming is atrocious: the verb is "allow", but this actually _displays_ a list of those unapproved? Was --show-blocked too obvious?

Upcoming breaking changes for npm v12

Related Stories