Lock Files and Package Manager Migration: A Practical Risk Analysis

Your package.json says "react": "^18.3.1". You run npm install today and get 18.3.1. Your coworker clones the repo next month and gets 18.4.0. Your CI server builds on Friday and gets 18.3.2. Same source code, three different dependency trees. This is the problem lock files solve — and the problem package manager migrations can reintroduce if you're not careful. This article breaks down how lock files work, why semantic versioning fails in practice, and how to migrate from npm to pnpm without losing the version guarantees your project depends on. Table of Contents What Lock Files Do and Why You Need Them Semver: The Theory vs. Reality Gap Migration Risk Matrix Safe Migration Playbook Managing Lock Files in Git 1. What Lock Files Do and Why You Need Them package.json Declares Ranges, Not Exact Versions Open any frontend project's package.json and you'll see dependency declarations like this: { "dependencies": { "react": "^18.3.1", "axios": "~1.7.0", "lodash": "4.17.21" } } These three n