Package manager
The tool that decides which versions of which dependencies a build sees, fetches them, and lays them out where the toolchain can find them. It is the layer this spoke owned in principle and held nothing on until 2026-09-04, even though monorepo and block-monorepo-migration both assume one.
Three jobs, and the third is where the designs diverge:
- Resolve — turn declared ranges into an exact version set, recorded in a lockfile.
- Fetch — get those versions onto the machine, ideally once per machine rather than once per project.
- Lay out — write a directory the language runtime resolves imports against.
Why the layout is the interesting part
In Node, the layout is the resolution algorithm: require walks up looking for node_modules, so
whatever the installer writes there defines what a program can import. npm and Yarn flatten —
transitive dependencies get hoisted to the root — which makes an undeclared dependency importable and
therefore invisible until the day it disappears. pnpm refuses the flattening and writes a symlink
tree in which only declared dependencies are reachable.
That makes correctness a property of the installer, not of the manifest, which is the same shape as the argument schema-driven-codegen makes about generated clients: the artifact enforces the contract, or nothing does.
The seam with this spoke's other pages
A package manager is build-and-ship infrastructure, so it is squarely here rather than in
../frontend-architecture-wiki (which owns how an application is divided) or
../agentic-tooling-wiki. The Ky precedent — an application-level runtime library is not dev-tooling
— cuts the other way for the installer that puts Ky on disk.
Related
pnpm · package-manager-benchmark-cheezone · monorepo · block-monorepo-migration · developer-tooling · synthesis