Breaking changes have had that tag for ages

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, the vibes (at the time) were that Microsoft has changed. Probably, in some way, a zero-interest rate phenomena.

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.

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.

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

"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

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/

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

---

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

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