Node And NPM Are Breaking Up? NodeJS TSC Has Important Conversation

The corepack discussions are getting more and more heated, it's about time we talk about it here. The days of yarn are over, and the results are a bit of a mess. Are we just doing this because pnpm is good? Or because bun is imminent? We have a lot to talk about

Huge huge HUGE shoutout to Sarah Gooding for her awesome blog post (linked below):

Sources

S/O Ph4se0n3 for the awesome edit 🙏

[vienzo]

Very good point at 13:27 - core node team seemed to be sitting around comfortably until yarn showed up and started mending things that yarn introduced to solve node's problems. fast forward many years, bun shows up and node team all of a sudden starts focusing on performance. well, be proactive, not reactive!

[ricky]

Make corepack the default, and add npm as the default option in the PackageManager field.

[CompletelyWoW]

"...a very old version of node.. like 16..." ...*thinks abour work repos*...*shudders*

[markeggers]

Make Corepack enabled as the default as a breaking change, and note it in the release notes. Not versioning your packaging system seems to be a bit scary. Whether or not npm decides to take advantage of that is another question. Yes, people will have to update their projects. Oh well.

I'm in favor of making a package manager's version controllable and enforceable by default. If you want to turn that off, you could do so. However, I think reproducible builds are an absolute necessity. Managing the version of your tool set is just as important as managing the versions of your artifacts.

Then again, I'm mostly a backend (Java) developer. We've been doing this for a long time. Build files have defined versions (sometimes ranges) of the tools in use. If the build environment does not pass those constraints, the build fails with one or more appropriate messages.

I'll say this again: A build must be reproducible regardless of the platform that it is run on. This is not negotiable. Any system that makes it easier to achieve reproducible builds is a win in my book.

[paljain]

why not enable corepack by default and add "npm" as fallback for "packageManager" key in the package.json

[familyshare]

NPM doesn't want a solution because it doesn't want competition.

[dominikdalek]

Having 3 questions up for voting, in this specific order, seems like a subterfuge. The correct first question should be whether to enable corepack by default (yes, obviously) and get back to the other questions once you get some adoption numbers. My gut feeling is that over a course of a year a lot of actively maintained projects will adopt explicit package manager requirement and problems around the implementation will be smoothed out. Argument from "we've always used npm and besides if it weren't for npm node would never succeed" is such a slimy thing to say. It's the "you owe us forever" mobster mentality and it's really, really bad.

[SeoFernando]

This discussion wouldn’t be an issue if NPM was actually up to par to other solutions like pnpm or Yarn.
It’s quite a shame for Node.
In other languages like python, go, rust the “alternative package manager” conversation is usually never brought up

[BrentMalice]

as someone who is newer to web dev, you and prime doin these sort of react videos are really helpful in guiding me along the right track and just letting me what kinds of things are important to even learn about.

saw you responding to comments that didnt like this so much and i can see where theyre coming from since its more like a talkradio than a news broadcast, but i like it. doin both is nice cuz i dont watch the super specific stuff that id never use

[gFamWeb]

I think the biggest confusing thing for me is how "npm" is the name of both the package manager, and the package repository. I think this co-naming is unnecessary, but its what we're stuck with.

I'm a firm believer in separation of concerns. I think package management and script running are two separate concerns. They should not be distributed together inseparably. But I also understand that they've been distributed that way for so long, that separating them *will* cause issues.

This would be a massive paradigm shift. I think the ideal state is decoupling, but I don't know if we could get there easily.

[metropolis]

One of the often touted strengths of Golang and Rust is that the package manager is builtin and a first class citizen. There are no real alternatives. One of the biggest criticisms of Python is that the package ecosystem is not only fragmented on the client side but also on the hosting side. Is JS, already suffering from too many choices for everything, going the Python road even more? While I love that yarn and pnpm fixed problems, they both are introducing huge problems by leading us to the endgame that Python is living atm.

[xcz]

I agree with you 100%, Theo. I use npm at work, pnpm for everything else. I wish we could easily make the choice of pm in the package.json. I had no idea I had to run 'corepak enable' to begin to do so.

[homawong]

Just enable corepack by default is sufficient IMO. Completely agree that the bundling of npm contributes to the success of JavaScript.

Look outside of JavaScript. Rust has and Go comes to settling a singular package manager. The bottom line is DX.

[ItsTheWhale]

A package manager for a package manager.
*Laughs in Deno*

[MadsterV]

I second the magic combo comment.
This is what I tell everyone. Sure, Node might not be as fast as some other languages, but getting a repo running is very straightforward.
You might be floored about people not knowing about Corepack (I didn't, either), but go ask around about other languages and their non-default package managers. Some don't use any. Every time you download a project, getting it to run is a coin toss. Sometimes the package manager goes under, so the dependencies can no longer be installed. Fun!
Node is ready to run in 3 lines, and they're (usually) always the same. This is the key to it's success and very much in line with JS' ease of use.

PS: sure you cringe at the "fairness is not useful" angle, while I cringe at the "fairness" angle itself. Of course NPM doesn't want to stop being the default. Of course the others want a shot at becoming the de-facto default. BOTH have vested interest, don't pretend one doesn't.
Finally: also splitting the registry would be a stab at Node's heart. Do you WANT pip and pip3? because this is how you get it.

[Wielorybkek]

I kind of agree that npm should stay. This is a thing about JS ecosystem I really don't like - you have 10 alternative libraries for every single thing and you have to maintain this mess by yourself. I don't care about it, shit should just work without me making all the decisions.

[jonkoops]

I have no problems having NPM by default, but it needs to be improved. Especially workspaces support needs to be expanded upon with support for wildcards to specify workspace packages as well as support for the `workspace:` protocol.

[elfensky]

I use voltash to specify node&npm versions. It works super well.
It adds a node and npm version fields to package json and automatically sets the correct version of node and npm when im in that project’s directory.

[BinaryReader]

Look, I think NPM should continue to be bundled with Node. However a better alternative would be to allow Node to source packages over arbitrary Http endpoints like Deno does. This means setting up a registry is no more difficult than setting up a static Http server. Until Node supports this, it should continue to bundle Npm, but with an understanding that a better "more open" approach would be to adopt what Deno does (and let the community manage their own registries)

[DanielNistrean]

Stop watching tech news. Theo and others make their living and status out of this. You should focus on your work. You don't need information overload.