On: pnpm: Fast, disk space efficient package manager for JavaScript

[hu3]

Is there any gotcha if I switch from npm to pnpm?

And can I use pnpm when working in a team where other devs use npm?

[scambier → hu3]

pnpm uses its own lock file (pnpm-lock.yaml), while npm uses package-lock.json

You definitely should use the same manager (npm, yarn, pnpm, whatever) as your teammates' or you're going to run into problems, either with them or with your CI workflow.

[hu3 → scambier]

thanks!

[inglor → hu3]

note: You can use `pnpm import` for converting a lockfile.json to a pnpm-lock.yaml

https://pnpm.io/cli/import

(This is not an endorsement of or recommendation of pnpm which I personally don't use daily)

[mmgutz → hu3]

I ran into glitches around the pnpm script that wrap binaries. I had to change VS Code launch settings to use node directly to invoke the package bin.

Some create scripts invoked via `pnpx create...` exit the terminal without showing prompts. No issues running those scripts when using npm or yarn. IIRC, that was happening on Windows + Windows Terminal.

The name is too close to npm. I'll inadvertently type `npm` and that starts downloading all dependencies again. Of course I press `Ctrl+C` which has led to corruption of the node_modules folder on a few occasions.

I would not recommend mixing pnpm and npm. pnpm uses its own lock file. There's no guarantee your app/library will be using the exact package versions everyone else is using. That leads to it-works-on-my-machine kind of bugs.

[jakubmazanec → hu3]

Pnpm doesn't auto install peer dependencies, which is annoying and forces you to unnecessary add them to package.json. Npm@7 (and newer) with auto install of peer deps is much easier to use in this regard.

[ricardobeat → jakubmazanec]

Isn't that exactly how it's supposed to be? If you're installing a package that has peer dependencies, you should already depend on them. Otherwise they are not "peer dependencies" anymore, just a normal dependency with a version range.

The whole peer dependencies story is another clusterfuck. Everyone simply ignored the invalid peer dependency warnings, and now npm itself will just install all of them in 'whatever works' version. To get real peer dependency resolution you need a --strict-peer-deps flag. Not exactly a "feature" in my book.

[jakubmazanec → ricardobeat]

I want to specify only those deps that I use directly. Imagine a `foobar` package, that has `babel` peer dependency because it does some transpiling or whatever. For me as a user of `foobar`, that Babel requirement could have been regular dependency instead of peer. I don't care, I don't use Babel. In another words - if a package manager has all the information necessary to install all dependencies, why should I add another, redundant information to my package.json?

[ricardobeat → jakubmazanec]

As the post you shared yourself explains, peer dependencies were meant for plugins/extensions. It would make no sense for you to depend on “foobar” directly without having babel as a dependency already.

If foobar can be used standalone, then babel is a standard dependency, not a peer dept.

[jakubmazanec → ricardobeat]

Technically true, but not how it is actually done. People very often specify packages like Babel, React, TypeScript, GraphQL, etc. as peer dependencies even when they shouldn't.

Anyway, in any case, auto installing peer deps solves both situations. There really is no reason to not auto install them.

[ricardobeat → jakubmazanec]

There really is - not everybody is content with having 600MB of unused dependencies being pulled in for no reason. This approach slows things down, including CI, increases surface area for security risks and makes your dependency tree inscrutable. All to account for obviously wrong use of the package manager.

[jakubmazanec → ricardobeat]

By "autoinstalling peer deps" I don't mean "installing unnecessary deps" - those peer dependencies are required, you still have to install them, I just don't want to manually add them to my package.json.

[ricardobeat → jakubmazanec]

We’ll, it’s hard to argue with that, we simply have very different expectations. You want NPM to automatically fix what is clearly user error so that installing random plugins “just works”, and don’t care that 3rd+ level deps might end up pulling a hundred extra packages you never asked for; I want it to follow its own dependency management rules to the letter and not have anything installed by surprise.

Clearly there is an audience for the former.

[jakubmazanec → ricardobeat]

Nothing is installed by surprise. Peer dependencies are not optional (you have to specify them as such). There is no user error and there is nothing for npm to fix.

I have some app:

  {
    "name": "some-app",
    "dependencies": {
       "foo": "^1.0.0"
    }
  }

foo specifies some peer dep:

  {
    "name": "foo",
    "peerDependencies": {
       "bar": "^1.0.0"
    }
  }
  

Now some-app doesn't directly use bar, so I didn't add it to package.json. Npm@7 and newer will install everything: foo and bar. If I used package manager without auto installing peer dependencies, I would have to manually update my package.json:

  {
    "name": "some-app",
    "dependencies": {
       "foo": "^1.0.0",
       "bar": "^1.0.0"
    }
  }
  

But in both cases node_modules will contain foo and bar. There are no "extra packages you never asked for". Adding bar as dependency of some-app is completely redundant information.

Now, it's possible that there are packages that don't really require some peer dependency installed, and therefore thery are installed needlessly. But that's problem of those poorly developed packages, not mine. Why should I waste time to manually specify what should and should not be installed?

[epolanski → jakubmazanec]

That implies babel was a dependency not a peer one.

Peer dependencies are for extensions and for plugins to an existing stack, as material-ui has a peer of react or io-ts on fp-ts

[jrochkind1 → jakubmazanec]

I am so confused about the purpose of a "peer dependency" in the first place then.

[jakubmazanec → jrochkind1]

You can read here why the peer deps were introduced: https://nodejs.org/es/blog/npm/peer-dependencies/

Imagine this structure of packages:

  your-app/
  ├── dep-a/
  │   └── dep-c
  ├── dep-b  
  └── peer-dep

Very simplified: `dep-c` is dependency of `dep-a`, so it is installed in its node_modules, but `peer-dep` is peer dependency of `dep-a`, so it is in node_modules of `your-app`. `dep-b` could also define `peer-dep` as its peer dependency, so it is installed only once. When npm switched to flat node_modules structure, peer deps become somewhat redundant, but not quite. Pnpm, which uses symlinks to achieve proper node_modules structure while avoiding long filenames, combined with auto install of peer deps would be ideal package manager.

[Wronnay → ricardobeat]

Yeah - this peer dependency thing always makes issues, when I try to upgrade a big Ionic project...

Peer dependencies added more problems than they solved in my eyes... Most peer dependencies warnings come because some maintainer forgot to update the package.json and not really because two packages don't work with each other...

[eyelidlessness → Wronnay]

The point of peer dependencies is to allow users more flexibility in choosing the specific version of the dependency. It’s not intended to specify any kind of conflict between the packages, it’s effectively BYO sub-dependency.

[jrochkind1 → eyelidlessness]

regular traditional dependencies can already be specified as a range, yes? Any range the specifier wants (and can legitimately work with), yes?

What is it about peer dependencies that give the host more flexibility in choosing the specific version?

Real question, not a challenge! I really don't understand this stuff, I've always found javascript dependency management very confusing.

[eyelidlessness → jrochkind1]

It allows packages to specify a wider version range for downstream users than a pinned version used in `devDependencies`. This is a common pattern if (say) your tests depend on certain less stable APIs but your published package only uses a smaller more stable subset. It’s especially useful if you want to support older semver-major versions, or even newer ones if you’re confident that the APIs you use will remain stable.

The example used in this post[1] on the Node blog is plugin systems, which is a very common expression of this pattern.

> Real question, not a challenge! I really don't understand this stuff, I've always found javascript dependency management very confusing.

I appreciate the clarification but it was clear to me the question was sincere FWIW! And yeah, a lot of this was hard for me to get a solid grasp on for quite a while. I think this tends to show up more in the JS ecosystem because semver was so eagerly adopted there, but I suspect it’s of similar benefit where semver is used and dev/prod dependencies is a proscribed distinction generally.

1: https://nodejs.org/es/blog/npm/peer-dependencies/

[chain-- → jrochkind1]

I could be wrong but I think it is used to alert you when you have incompatible dependencies.

For example if you have a dependency with a peerDependency `something: 2.x.x` and you currently have `something: 1.0.0` installed as a direct dependency, it will fail rather than allowing multiple versions to be run.