pnpm

pnpm stores package contents once in a content-addressed global store and hard-links projects into a strict `node_modules` layout. Only declared dependencies are importable—a common interview differentiator from flattened npm layouts.

| Feature | Effect | |---------|--------| | Content store | Deduped disk usage across repos | | Strict layout | Undeclared transitive imports fail early | | Workspaces | Monorepo installs with `pnpm-workspace.yaml` | | Filters | `pnpm --filter <pkg> test` targets one package |

					# pnpm-workspace.yaml
packages:
  - 'apps/*'
  - 'packages/*'
				

`pnpm-lock.yaml` pins the resolved graph. Teams pin pnpm with `packageManager` in root `package.json` so CI and laptops use the same version.

On interviews: explain speed from linking, why phantom dependencies break under pnpm, workspace filters, and when deliberate hoisting (`public-hoist-pattern`) is needed for legacy tools.

Common pitfalls: tools assuming flattened `node_modules`; different pnpm versions changing lockfile format; CI not using Corepack or pinned pnpm.

The trade-off is strictness and disk efficiency versus occasional ecosystem compatibility work.

Checklist:

• Understand strict dependency resolution.
• Use workspace filters for monorepos.
• Pin pnpm version across environments.
• Hoist only deliberately for incompatible tools.