All 15 Git & Project Management questions
More in Git & Project Management
What is the purpose of a package-lock.json file in a Node.js project, and why should it be committed to version control? What is the purpose of a .gitignore file in a Node.js project, and what should always be included in it? What is the purpose of a CHANGELOG.md file in a Node.js project, and what should typically be included in each entry? What is a monorepo, and what specific tooling (like npm workspaces or Turborepo) helps manage multiple related Node.js packages within a single repository? How would you set up branch protection rules and required status checks for a Node.js repository to prevent broken code from being merged? What is the difference between npm, Yarn, and pnpm as Node.js package managers, and what specific advantage does pnpm offer regarding disk space? What is a pull request template, and how does it help standardize code review in a Node.js team's Git workflow? What is the purpose of an npm 'scripts' section in package.json, and how do custom scripts standardize common project tasks across a team? How would you use Git hooks (like a pre-commit hook via Husky) to enforce code quality checks before code is committed in a Node.js project? How would you structure conventional commit messages in a Node.js project, and how do they enable automated changelog generation?
Advertisement
Back to results for “Deployment”
Node.js › Git & Project Management

What is semantic versioning (semver), and how does it inform how a Node.js package's version number should change between releases?

Intermediate

Answer

Semantic versioning uses a MAJOR.MINOR.PATCH format, where a PATCH increment indicates a backward-compatible bug fix, a MINOR increment indicates new backward-compatible functionality, and a MAJOR increment indicates a breaking change -- consumers of a package rely on this convention (combined with caret/tilde ranges in package.json) to safely receive automatic bug-fix and feature updates without breaking their application, while being explicitly warned (and required to manually opt in) when a breaking major version change occurs.
// package.json version ranges leveraging semver conventions
"dependencies": {
  "lodash": "^4.17.0", // accepts any 4.x.x update, but not 5.0.0
  "express": "~4.18.0" // accepts only patch updates within 4.18.x
}
Real-world example A library maintainer accidentally introduces a breaking API change in what was tagged as a minor version release, causing widespread downstream failures for consumers who had reasonably trusted the semver convention that a minor bump wouldn't break their code; the fix involves yanking the release and re-publishing the breaking change as a proper major version instead.

Common follow-ups: What's the practical consequence for downstream consumers when a maintainer violates semver conventions like this?;How do automated tools like semantic-release determine the appropriate version bump automatically based on commit messages?

npm & Packages;CI/CD Publishing & Deployment
All 15 Git & Project Management questions