Generally I've found sticking with npm to be best. It's not the super-slow thing that it was before, and I can't remember the last time a package didn't install because it wasn't compatible with npm.

I tried pnpm and it didn't just work, so I gave up. I would revisit it, but npm works.

These days I don't really see a reason to use yarn (but would like to hear them).

Yarn's workspaces provide some cool benefits to monorepos which AFAIK npm hasn't matched. You can get there with Lerna + npm, though.

I have so far had very good npm workspace experience. Just define "workspaces" property in package.json and your off. https://docs.npmjs.com/cli/v8/using-npm/workspaces

Right now only pain-point with npm is that "npm link" can't be forced to install peer dependencies so I'm unable to easily test typesscript built libraries within other projects.

For what it's worth Yarn 3 implements essentially all modes. It can do standard node_modules, its own Plug'n'Play, as well as pnpm-style hardlinking to a global cache.

Edit: I just learned from another comment that PNPM also supports Plug'N'Play :) Thanks steven-xu!

pnpm as well supports all three modes. But I think it is better to use Yarn for the PnP mode and pnpm for the symlinked mode.

Here is a feature comparison: https://pnpm.io/feature-comparison

So it should just be backported to npm to show that the authors are serious about backwards compatibility.

Both pnpm and Yarn are independent projects maintained by the community. I personally think that these are better projects than npm CLI because they can make their own decisions. Not decisions dictated by business needs of a company.

I was OK to merge pnpm into npm in the past. They have never suggested me this opportunity. Instead, they decided to re-implement pnpm's algorithm into npm and call it "isolated mode".

I see, I tried it now, it looks great.

Most of my problems were created by the material UI libraries (I wanted to use them with SvelteKit), but I just got rid of it as those libraries were making development harder instead of helping.

I still wish there would be a nice UI library for Svelte, but I guess that's the disadvantage of not going with the mainstream frontend toolkit.

> ...material UI libraries...making development harder instead of helping.

I'm glad I'm not the only one who has had that experience.

Material UI (MUI for react) not just impact the DX, it also bloats the runtime impacting the UX

That's literally xkcd #927: let's make a standard that encompasses all previous standards, what can go wrong?

Now you have to maintain three different code paths, two of which depend on the behaviour of external projects, so you're always playing catch up.

That's such a bad idea on so many levels.

Given what a dumpster fire npm ecosystem is security wise, it's best to run the whole build chain in a container anyway, at least for frontend apps. This way you also don't care about the chosen package manager or node.js version - you can just set it as you wish in the Dockerfile. It does take more disk space though, but to me it's a nice compromise.

Containers don't provide much protection from malware, unless you're running it rootless under an unprivileged user (no sudo access, no ssh keys or anything else interesting in the home directory, etc; and even then it's limited because the attack surface is enormous).

I mean, of course? Especially, why would I put ssh keys and similar in the container?

This still doesn't mean that one can install just any package, but it does make it much more difficult for it to do much harm. Breaking out of a container is not as trivial as it once was. That said, it is not a perfect solution, so I'd be happy to hear of better ones. Any suggestions?

No ssh keys or anything else interesting available to the user you're running the container engine under (and containers themselves). Not the user _inside_ the container, but on the main system.

gVisor, VMs

> If there are clearly better algorithms, why not refactor npm and add them in experimental flags to npm

While node_modules has many flaws, in the current ecosystem all modes have their own pros and cons, and there isn't a "clearly better" algorithm: node_modules has less friction, PnP is sounder, and pnpm's symlinks attempt to be kind of an in-between, offering half the benefits at half the "cost".

Like in many computer science things, it's tradeoffs all the way. Part of why Yarn implements all three.

pnpm also implements all three: https://pnpm.io/feature-comparison

But I think it is best to use Yarn for PnP and pnpm for the symlinked node_modules structure.

Because npm maintainers do not, and apparently have never known, how a good package manager is supposed to work.

I have zero trust in NPM.