What's the practical trade-off between pinning a dependency to an exact version versus letting it float within a range, and how do teams get the benefits of both?

## The two questions a declaration answers Every dependency declaration is really answering two different questions that pull in opposite directions: 'what version do I want to run in production right now, exactly and reproducibly?' and 'what versions am I willing to accept as I keep building over time?' | Declaration | Answers | What it does | |---|---|---| | A **pinned/fixed** version — `4.17.21` with no operator | only the first question | names one specific, immutable artifact, and every install of that manifest resolves to that artifact and nothing else | | A **floating range** — `^4.17.0`, or a Maven interval like `[4.17.0,5.0.0)` | the second question | names a set of acceptable versions and defers the actual choice to whatever the resolver finds newest and valid at install time | ## When the version decision gets made The mechanism difference matters because it changes when a version decision gets made. - **With a pin**, the decision was made once, by whoever wrote or last updated that line, and it never changes again until someone edits the file. - **With a range**, the decision is remade every time the resolver runs against the registry, which means the same manifest file can produce different installed code on different days, machines, or CI runs, purely because upstream packages kept publishing. ## Why ranges exist Ranges exist because pinning doesn't scale as a maintenance strategy. A modern application can have hundreds or thousands of transitive dependencies; if every one of them were pinned exactly, picking up a single critical security patch three levels down the tree would require manually walking the graph, bumping every affected pin, and re-testing — for every disclosure, on every project, forever. Ranges let a resolver absorb that churn automatically as long as upstream maintainers honor semver's compatibility promise, which is the whole reason semver exists as a convention in the first place: it gives a machine enough information to decide 'is this new version safe to auto-adopt' without a human reading a changelog. ## The cost of floating The cost of floating is reproducibility, and it shows up as two related but distinct risks. 1. **First, non-determinism:** two installs of the same manifest, run at different times, are not guaranteed to produce the same dependency tree, which breaks the ability to say 'this exact build passed CI, therefore it's safe to ship' unless something else pins the resolution down. 2. **Second, supply-chain exposure:** a range means the project is implicitly trusting every future publish an upstream maintainer makes into that range, including ones that violate semver by accident, or — in rarer but real cases — ones published maliciously after an account or package name is compromised. A wide-open range widens that trust surface without the team ever reviewing what changed. ## The two-file model The standard way teams get both benefits is a **two-file model**. - The **manifest** — `package.json`, a Gradle build file, a Maven `pom.xml` — declares intent using ranges, expressing 'anything compatible is fine.' - A separate **lockfile** — `package-lock.json`, `yarn.lock`, `Gemfile.lock`, or Gradle's dependency locking feature — records the fully resolved, exact version of every direct and transitive dependency from a specific, deliberate resolution. Day-to-day and CI installs use a strict, lockfile-only install command (`npm ci`, `bundle install --deployment`, `yarn install --frozen-lockfile`) so that every machine gets byte-for-byte the same tree the lockfile describes, regardless of what's newest in the registry right now. New versions only enter the picture when a human — or, more commonly today, an automated bot like Renovate or Dependabot — deliberately regenerates the lockfile, opens a pull request with the diff, and lets CI and code review gate the change before it merges. This turns 'automatic silent drift' into 'automatic proposal, manual approval,' which is the actual industry-standard answer to the pin-vs-float trade-off rather than picking one extreme. ## A concrete scenario A concrete scenario makes the stakes clear: a team ships a Node service with `"express": "^4.18.0"` in `package.json` but no lockfile committed to the repo (a surprisingly common oversight in fast-moving projects). Every deploy pipeline run does a fresh `npm install`, re-resolving the caret range against the npm registry at that moment. Six months in, a transitive dependency of Express publishes a patch that subtly changes error-handling behavior for a rare edge case; the service starts returning malformed error responses in production with zero corresponding commits in the team's own repository, because the change came entirely from range re-resolution. The fix isn't a code change at all — it's committing a lockfile going forward and pinning the currently-working tree, converting an invisible floating dependency into a reviewed, deliberate one.