Знаком ли с семантическим версионированием

Что проверяют

Понимаете ли вы, что номер версии это обещание о совместимости, и как npm этим обещанием пользуется. Следом почти всегда спрашивают про разницу между ^ и ~ и зачем нужен lock-файл.

Как отвечать

Формат MAJOR.MINOR.PATCH:

• MAJOR: несовместимые изменения публичного API. Удалили проп компонента, поменяли сигнатуру, подняли минимальную версию Node или React в peerDependencies;
• MINOR: новая функциональность без поломки старой;
• PATCH: исправления без изменения API;
• пре-релиз: 2.0.0-beta.1, он младше 2.0.0, и обычные диапазоны его не подхватывают;
• метаданные сборки: +build.5, на порядок версий не влияют.

Отдельный случай 0.x: публичный API ещё не зафиксирован и может ломаться в любой версии.

Диапазоны в package.json: npm install по умолчанию сохраняет ^. ^1.4.2 разрешает всё до 2.0.0, ~1.4.2 только патчи до 1.5.0. На нулевой версии каретка строже: ^0.4.2 не выйдет за 0.5.0. Точные версии фиксирует package-lock.json (или pnpm-lock.yaml, yarn.lock), а в CI ставят через npm ci, который берёт ровно то, что записано в lock-файле.

Свой пакет поднимают командой npm version minor, она же создаёт git-тег. В монорепозиториях используют Changesets, в библиотеках semantic-release: по Conventional Commits fix: даёт патч, feat: минор, feat!: или BREAKING CHANGE: мажор.

Где спотыкаются

Считают, что semver гарантирует совместимость. Это договорённость авторов, и поломка в миноре случается. TypeScript, например, semver не следует, поэтому его версию часто фиксируют через ~.

Удаляют lock-файл, «чтобы починить зависимости». Вместе с ним в проект приезжают сотни непроверенных обновлений транзитивных пакетов.

Не считают мажорным то, что не видно в коде: отказ от поддержки старого браузера, переход сборки с CommonJS только на ESM, изменение поля exports в package.json.