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.

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

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.

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.

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.

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

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.

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.

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

[delayed]

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!

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

Deterministic to a fault unless you mix Windows and Linux.

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

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

[dead]

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

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

it was all good until AI entered the chat

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.

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.

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

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

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

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

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.

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

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.

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

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

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

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

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

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.

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.

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

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

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.

> 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

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.

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.

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

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

Breaking changes have had that tag for ages

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.

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

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.