A team is deciding whether to write exact pinned versions in their dependency manifest (no ranges at all) or keep caret/tilde ranges in the manifest while relying on a committed lockfile for reproducibility. What do they actually gain or lose with each approach?

## Two axes people conflate At the core, this question conflates two independent axes: what the manifest says is acceptable, and what actually gets installed. - A range like `^18.2.0` in `package.json` is a **policy statement** -- 'I'm compatible with anything from 18.2.0 up to but excluding 19.0.0' -- evaluated by semver rules. - An **exact pin** like `18.2.0` with no caret is a stricter policy: 'only this exact version satisfies me.' - Separately, the **lockfile** records what was actually installed the last time resolution ran, as an exact version regardless of what the manifest range allows. Once a lockfile exists and is respected by the install command, day-to-day installs are equally reproducible whether the manifest uses ranges or exact pins, because the lockfile -- not the manifest -- drives what gets fetched. So teams debating 'ranges vs pins' for reproducibility alone are often solving a problem the lockfile already solved. ## Upgrade ergonomics and deduplication Where the two approaches genuinely diverge is upgrade ergonomics and dependency deduplication. - **With ranges,** tools like `npm update` or automated dependency bots (Dependabot, Renovate) can bump a dependency within its allowed envelope and the lockfile PR shows a minimal, reviewable diff: version X.Y.Z to X.Y.Z+1, nothing else needs to change in the manifest. - **With exact pins in the manifest,** every intentional bump requires editing the manifest's version string too, which is more explicit (you see the version change in the manifest diff) but adds friction, especially across many packages in a monorepo -- some teams find that friction valuable because it forces a deliberate decision per dependency; others find it just adds churn for routine patch bumps. ## Why the shape of the graph matters more to libraries The other real divergence is dependency graph shape, which matters far more for libraries than applications. If a library's own manifest hard-pins its dependencies to exact versions, then any consumer application that also depends (directly or transitively) on a slightly different version of that same package cannot dedupe -- npm/yarn/pnpm can normally collapse two dependents that both accept, say, `^4.0.0`, onto one shared install of a package, but if one insists on exactly `4.0.0`, you get two copies installed side by side, larger bundles, and sometimes broken invariants (e.g. two different React copies causing 'Invalid hook call' errors). This is why libraries conventionally use ranges (and typically do not rely on a committed lockfile for consumers at all) while applications use ranges plus a committed lockfile: the range communicates the compatibility contract to the ecosystem, and the lockfile (application-only) nails down what that application specifically runs. ## Ranges plus lockfile against exact pins The trade-off, stated plainly: | Approach | What you get | And what you pay | |---|---|---| | **Ranges plus lockfile** | give you automatable, low-friction, low-diff-noise upgrades and better cross-package deduplication | at the cost of a subtle failure mode -- if the lockfile is ever deleted, corrupted, or bypassed (e.g. someone runs install with a no-lockfile flag, or a Docker layer doesn't copy it in), the ranges alone can resolve to a materially different, untested version | | **Exact pins in the manifest** | give you a second line of defense against exactly that scenario -- even without a lockfile, the manifest itself fully constrains the install | at the cost of manual, per-dependency upgrade overhead and worse deduplication if you're a library | ## How it shows up in production In production this shows up as: a Dockerfile that copies `package.json` and runs install without also copying `package-lock.json` -- with ranges, every image rebuild can silently drift to newer transitive versions (a classic non-reproducible-build bug); with exact pins in the manifest, at least the direct dependencies stay fixed even without the lockfile, though transitive ones still aren't controlled without one either way. A well-known pattern that sidesteps most of this debate is combining a 'one version per dependency across the whole repo' policy with committed lockfiles and bots configured to open small, individually reviewable PRs for each bump -- getting ranges' automation benefit without losing reviewability.