Why does “pnpm run” run in current package but “pnpm install” installs all packages?

[gaggle]

Can anyone shed light on why pnpm has chosen to have “pnpm run” operate on the current folder’s package by default, but “pnpm install” installs all packages by default?

Or put another way: If I go to a specific package why should I be “burdened” with the entire repo’s worth of packages? I just want the package I have open (plus its dependencies).

I don’t mind pnpm’s current behaviour, but I’d love to hear if there are explicit reasons for it or if it just kinda evolved that way?

And at any rate thanks for making pnpm available, it’s truly been a pleasure to work with so far.

[zkochan]

All the packages in a workspace use a single lockfile and a single virtual store (at <repo root>/node_modules/.pnpm), so it would be hard to install dependencies of a single project in isolation. Also, there might be some shared dev dependencies in the root package.json of the workspace, so it makes little sense to ever not install the dependencies of the root package.json. In a previous version, pnpm install used to install only the dependencies of the project in the active working directory. But it was error prone. Installing everything is pretty fast with hot cache and saves a lot of headache.

[gaggle]

Ah thanks that's interesting. Just to clarify, today I can use pnpm install --filter <p>... to only install my current package, and that's the behavior I wondered if pnpm has considered offering by default so that I only get the packages I need rather than the repo's packages.

You make two points in particular I'd like to highlight:

It was error prone

I assume --filter is not error prone today, so I find this point historically interesting but also probably that it's not relevant if we hypothetically say pnpm for some reason wanted to switch to using --filter as its new default… but please tell me if I'm misunderstanding the point you were making.

pretty fast

I read this point to say that installing the whole repo has really not been an observed performance penalty, and I can easily imagine real-life monorepos have sufficient overlap in dependencies across the repo that its just simpler and only slightly/hypothetically slower to get everything installed at once.

Anyway, thanks for the answer and insight, and to be clear I like pnpm's current behavior so I appreciate it works this way :)

[zkochan]

I assume --filter is not error prone today

I am afraid you would meet some edge cases. We might disable the filter flag for the install command to reduce potential edge cases. Of course, --filter should work fine for all other commands.