What is semantic versioning and why does it matter for npm packages?
Semantic versioning uses MAJOR.MINOR.PATCH. Increase PATCH for bug fixes, MINOR for backward-compatible features, MAJOR for breaking changes, so users can judge upgrade risk from the number alone.
Explain it simply
Think of a mobile app update. A tiny bug fix should not change how the app looks. A big redesign might move your buttons around. Semantic versioning, or semver, gives each kind of change its own number so you know what to expect before you update.
Given version 3.7.2:
3is MAJOR: incompatible API change. Your code may need edits.7is MINOR: new feature added, old code still works.2is PATCH: bug fix only.
When a major number goes up, minor and patch reset to zero, so 3.7.2 becomes 4.0.0 after a breaking change.
Example
npm version patch # 1.4.2 -> 1.4.3
npm version minor # 1.4.3 -> 1.5.0
npm version major # 1.5.0 -> 2.0.0npm version also creates a git commit and a tag by default. Ranges like ^1.4.2 in package.json depend on authors following semver, since npm will happily install a new minor version automatically.
Versions below 1.0.0 are treated as unstable; the author may break things in a minor release.
What to say in the interview
"Semver is MAJOR.MINOR.PATCH: breaking, feature, fix. Package managers use it to decide which updates are safe to auto-install, so publishing a breaking change as a patch would break everyone's builds."
Common mistakes
- Publishing a breaking change as a minor or patch release.
- Assuming every package follows semver strictly; the lock file protects you.