5 ms·

As a person who uses npm just for some hobby coding projects, it's quite frustrating that there are new partly incompatible package managers for the javascript

As a person who uses npm just for some hobby coding projects, it's quite frustrating that there are new partly incompatible package managers for the javascript ecosystem: npm, pnpm, yarn, yarn 2. Some packages need one, some another, so I tried to switch to yarn (or yarn 2) for a package that I wanted to try out, but then other packages stopped working. If there are clearly better algorithms, why not refactor npm and add them in experimental flags to npm and then setting them to default as they mature (with safe switching from one data structure or another)?

Cu3PO42 5y ago
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!
- zkochan 5y ago
  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 https://pnpm.io/feature-comparison
- xiphias2 5y ago
  So it should just be backported to npm to show that the authors are serious about backwards compatibility.
  - zkochan 5y ago
    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".
    - xiphias2 5y ago
      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.
      - girvo 5y ago
        > ...material UI libraries...making development harder instead of helping. I'm glad I'm not the only one who has had that experience.
        aabbcc1241 5y ago
        Material UI (MUI for react) not just impact the DX, it also bloats the runtime impacting the UX
- sph 5y ago
  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.
arcatek 5y ago
> 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.
- zkochan 5y ago
  pnpm also implements all three: https://pnpm.io/feature-comparison https://pnpm.io/feature-comparison But I think it is best to use Yarn for PnP and pnpm for the symlinked node_modules structure.
vosper 5y ago
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).
- lelandfe 5y ago
  Yarn's workspaces provide some cool benefits to monorepos which AFAIK npm hasn't matched. You can get there with Lerna + npm, though.
  - citrons 5y ago
    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 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.
trulyme 5y ago
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.
- 5e92cb50239222b 5y ago
  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).
  - trulyme 5y ago
    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?
    - 5e92cb50239222b 5y ago
      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.
    - gizzlon 5y ago
      gVisor, VMs
Aeolun 5y ago
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.

Cu3PO42 5y ago

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!

zkochan 5y ago
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 https://pnpm.io/feature-comparison
xiphias2 5y ago
So it should just be backported to npm to show that the authors are serious about backwards compatibility.
- zkochan 5y ago
  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".
  - xiphias2 5y ago
    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.
    - girvo 5y ago
      > ...material UI libraries...making development harder instead of helping. I'm glad I'm not the only one who has had that experience.
      - aabbcc1241 5y ago
        Material UI (MUI for react) not just impact the DX, it also bloats the runtime impacting the UX
sph 5y ago
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.

arcatek 5y ago

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

zkochan 5y ago
pnpm also implements all three: https://pnpm.io/feature-comparison https://pnpm.io/feature-comparison But I think it is best to use Yarn for PnP and pnpm for the symlinked node_modules structure.

vosper 5y ago

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

lelandfe 5y ago
Yarn's workspaces provide some cool benefits to monorepos which AFAIK npm hasn't matched. You can get there with Lerna + npm, though.
- citrons 5y ago
  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 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.

trulyme 5y ago

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.

5e92cb50239222b 5y ago
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).
- trulyme 5y ago
  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?
  - 5e92cb50239222b 5y ago
    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.
  - gizzlon 5y ago
    gVisor, VMs

Aeolun 5y ago

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.