Upcoming breaking changes for npm v12
github.blog452 points by plasma 20 hours ago
452 points by plasma 20 hours 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.
Happened in 2020 apparently
https://github.blog/news-insights/company-news/npm-is-joinin...
Strategical positioning for enshittification, control and future squeezing of profits. Embrace, Extend, Extinguish.
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
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?
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.
>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).
At this point I will not do any dev outside of a container - so many things can be supply chained in the OSS dev stack it's just not worth it, and once you get used to developing in containers it's actually a lot cleaner to move between hosts - you're essentially treating your client as a remote terminal.
If you're doing web dev work in this day an age SSH with tmux or some editor with SSH server support should be your dev setup.
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.
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.
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.
Then don't use it. Just don't presume to tell me if I can or can't.
Given that has an impact over the whole industry, I will for sure tell you that patching on install SHOULD NOT be a thing. Up to you to run your own post install script yourself
It absolutely should and maybe I'll run and advertise a fork that will behave properly. Yay open-source.
Or maybe just add a script in package.json to run whatever patch-package does (eg, "install:patch": "npm install && patch-package") instead of whitelisting every package to have that power.
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.
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!
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
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
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.
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?
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 improvements.
Disclaimer: I'm the Yarn lead maintainer.
It was a giant mistake to keep 'classic' (umnaintained, unpatched) yarn around. Switched to pnpm in part due to that reason.
It's not exactly unmaintained (we merged a couple of security patches in the past years), I agree that we should have do something about it.
We'll be correcting this situation starting from the 6.x release, which we expect somewhere in August.
Deterministic to a fault unless you mix Windows and Linux.
As mentioned in the issue you link the problem comes from third-party packages with non-deterministic build scripts in git dependencies, or files on disk being actually different (although I guess we could at least try to normalize crlf, but as you can guess it will break someone).
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...
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
I don't know what NPM is doing, but yarn installs deps much faster than NPM
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 the people downvoting my comment: Feel free to answer my question. I really don't know the answer.
didn't know npm was owned by github.. well, that explains things...
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.
> ...
To be fair, the vibes (at the time) were that Microsoft has changed. Probably, in some way, a zero-interest rate phenomena.
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. Edge is built on Chromium.
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.
Do microsoft own git now?
I don't think so
Pedantically no, but in practice almost yes. So many programmers born after 2006 think that Git and GitHub are the same thing.
Good luck migrating the ”forge” part with the ”git” part. Your github org settings, pull requests, rulesets, CI/CD pipelines, containers, copilot... The lock-in always comes from the ”forge” part, never the ”git” part.
> GitHub didn’t embrace, extend, extinguish git.
Literally nobody has said that it did? This is a wild strawman. Who are you trying to fool.
> 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.
Old folks are also aware that applies to every single big tech company that actually sponsors the FOSS tools many don't want to pay anything back, while expecting to be paid themselves.
Old folks also remember the days when it was possible to make a living out of selling software tools.
The ruthlessness of the Microsoft that we remember was probably due to influence from Bill Gates.
He is famous for hyper-competitiveness and strong desire to win at all costs.
Microsoft has been causing a lot of problems lately but I completely disagree that it fits the pattern of "embrace, extend, extinguish".
Remember when folks thought Phil Spencer was gonna right the Xbox ship lol
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 was part of the npm team at GitHub. They laid off almost the entire team to focus on AI (CTO literally told us on the layoff announcement call that they're doing this to focus on Copilot)
> they fired many staff engineers
Would you rather the company went under after it ran out of money and had to fire everyone instead? Not to mention a quarter of the company was laid off the year before the acquisition.
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.
No one said anything about bankruptcy, you seem to have made that up for your "argument" or whatever this is. The company didn't have a viable business model and was running out of cash. MSFT right-sized the team for the project they wanted it to be, rather than the business model the prior company was trying to be.
Yeah, it's like people are forgetting that the executive team at GitHub was composed of sex pests and people defending said sex pest. Of course they'll call any attempt at unionizing as "damaging" to the company and must be blamed accordingly!
After all the company was in such dire straights that they were acquired for $7.5 billion! Only companies with terrible prospects get acquired, that's just business 102.
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.
Google said you are 100% wrong.
Right, the very public two rounds of layoffs the company did right before being "acquired" had nothing to do with them running out of money.
Not my job to proof the wild claim that the layoffs were to save the company from bankruptcy .
The company raised $10M, did two rounds of layoffs totaling a quarter of the company, and was then acquired not long after. Early stage companies like that don't do layoffs unless it's to extend cash runway, but run wild with whatever unfounded fantasy you have about it all.
Uhh, I'd expect the trillion dollar transnational corporation to do right by it's workers rather than rat fucking them to appease corporate do-nothing leeches if I'm being frank.
> I'd expect the trillion dollar transnational corporation to do right
you would? has any trillion dollar corporation ever?
No, and that's why we must destroy them. Figuratively then literally.
Destroy what exactly? And replace with what?
With smaller companies that can't yield global power. It would be better if cloud, office and OS would be separate. Then you wouldn't get shuffed OneDrive into the OS. It's also better for competition if the playing field is equal and one solution isn't the only one that can deeply integrate. Build APIs or don't do it.
Can y’all just state your opinions on these things rather than constantly asking bait-y questions?