Semver Checks

semver-checks

pino 10.4.0, a minor release, added export { pino as default, pino } inside its pino namespace. That turns off implicit export for 9 members of the namespace, so const t: pino.TimeFn = () => '' compiles against 10.3.1 and fails against 10.4.0 with TS2694, "Namespace 'pino' has no exported member 'TimeFn'".

npx semver-checks compare pino@10.3.1 pino@10.4.0

Run with no arguments in a publishable package directory, npx semver-checks compares @latest against .. This default is CLI-only: the GitHub Action and the MCP semver_compare tool need old explicitly.

semver-checks — Recommended bump: MAJOR

major: 20 (confident: 11, review: 9) minor: 88 patch: 0

Breaking Changes — confident (MAJOR) ✗ Export 'TimeFn' was removed was: type-alias ✗ Export 'MixinFn' was removed was: type-alias ✗ Export 'MixinMergeStrategyFn' was removed was: type-alias ...

The output is trimmed to the bump counts and three of the 9 removed exports (... marks the cut, and stderr warnings are omitted); the full run also lists the other six, two required properties added to MultiStreamRes, the review-only findings and the additions.

semver-checks compares the TypeScript declarations on both sides and recommends the bump the type changes require, so the answer comes from the API rather than from the commit message. Neither side needs a checkout: each can be an npm spec, a git ref, or the working tree.

npx semver-checks compare your-package@latest .

The same check as a pull request gate, which annotates the changed lines and fails on a proven break:

# .github/workflows/semver-check.yml

on: pull_request jobs: semver-checks: runs-on: ubuntu-latest steps:

• uses: actions/checkout@v4
• uses: actions/setup-node@v4 with: node-version: "22"
• run: npm ci
• uses: kyungseopk1m/semver-checks@v0.17.0 with: old: "your-package@latest" strict: "true"

Every input, and the release-pull-request variant that grades the declared bump and posts the verdict as a comment, are under GitHub Action.

• Why semver-checks?
• Quick Start
• CI Integration
• Accuracy
• Programmatic API
• Reference
• FAQ

Why semver-checks?

A bump is a claim about what a release did to its public API, and it is usually written by hand, from memory, at the end of the work. A refactor that drops a required export reads as a patch to the person who wrote it and as a broken build to everyone downstream.

Release tooling can only act on the evidence it is given. semantic-release derives the release type from commit conventions, and changesets records an author-written release note with the bump declared in its frontmatter. Both inherit whatever the author believed at the time.

semver-checks reads the public API directly using ts-morph and decides the bump from what the type signatures did.

The example above is not constructed. Run the tool across real releases and it finds breaking type changes that shipped as minors and patches. It is most dependable on structural changes, which is to say removed or renamed exports, narrowed signatures, and added required parameters and properties. Equivalence-preserving type rewrites are a known weak spot it can over-report, and docs/accuracy.md says exactly where to trust it and where not to.

// v1.0.0

export interface Config { host: string; port: number; }

// Developer writes: "fix: add missing timeout config" // Published as patch — but this is a MAJOR change: export interface Config { host: string; port: number; timeout: number; } // ^^^^^^^^^^^^^^^^ required-property-added

// v1.0.0

export function findUser(id: string): User;

// Developer writes: "fix: findUser can come up empty" // Published as minor — but no existing consumer is written to handle null: export function findUser(id: string): User | null; // ^^^^^^^^^^^ return-type-changed (MAJOR)

The reverse of that change is not a break: narrowing User | null down to User hands every consumer a value they were already prepared for, and semver-checks reports it as return-type-narrowed, a MINOR.

semver-checks is complementary to your existing release workflow. Use it as a verification step before publishing — it tells you whether your intended bump is safe, or whether you're about to ship a breaking change by accident.

Quick Start

npm install --save-dev semver-checks

Compare a git tag to the latest commit:

npx semver-checks compare v1.0.0 HEAD

Compare the published npm release against your working tree — answers "is my current change a breaking release?" without needing git tags:

npx semver-checks compare your-package@latest

A @ argument is fetched from the npm registry (via npm pack) and used as the old version. Concrete versions, ranges, and common dist-tags are auto-detected (your-package@1.2.3, your-package@^1, your-package@next). For an uncommon dist-tag, make the intent explicit with the npm: prefix or --old-as npm (npm:your-package@my-custom-tag) so it isn't mistaken for a git ref.

Compare two local directories:

npx semver-checks compare ./old ./new

Existing relative paths without a ./ prefix are also treated as local directories:

npx semver-checks compare packages/core packages/core-next

If a git ref collides with an existing path name, force ref interpretation explicitly:

npx semver-checks compare main HEAD --old-as ref

Output as JSON, Markdown (for PR comments), or GitHub Actions annotations:

npx semver-checks compare v1.0.0 HEAD --format json

npx semver-checks compare v1.0.0 HEAD --format markdown npx semver-checks compare v1.0.0 HEAD --format github

Fail in CI if breaking changes are detected (exit 1):

npx semver-checks compare v1.0.0 HEAD --strict

Inspect the API surface of the current or a past version:

npx semver-checks snapshot

npx semver-checks snapshot --ref v1.0.0 npx semver-checks snapshot --npm p-limit@6.1.0

Every flag is in docs/cli.md.

Multiple entry points

When package.json declares an "exports" map with several subpaths, every subpath with a declared .d.ts entry is extracted and compared independently. Adding a subpath is a MINOR change and removing one is MAJOR; a change inside a subpath is reported with a # separator (e.g. ./utils#helper). No flags are needed — the map is auto-detected.

For projects without an "exports" map, pass multiple entries explicitly by repeating --entry or comma-separating them:

npx semver-checks compare v1.0.0 HEAD --entry src/index.ts --entry src/utils.ts

npx semver-checks compare v1.0.0 HEAD --entry src/index.ts,src/utils.ts

Example output

semver-checks — Recommended bump: MAJOR

major: 2 (confident: 1, review: 1) minor: 1 patch: 0

Breaking Changes — confident (MAJOR) ✗ Required property 'timeout' was added to interface 'Config' now: number

Needs review — couldn't prove safe (MAJOR) ? Call signatures of interface 'Middleware' changed before: (req: string) => void after: (request: string, next?: (() => void) | undefined) => void

New Features (MINOR)

• Export 'createConfig' was added

The second finding is a renamed parameter and an added optional one, which oblige nobody — but call signatures are compared as printed text, so the tool cannot prove that and says so instead of guessing. --strict exits 1 on the confident break only; the review-only item passes the gate unless you opt into --strict-review.

CI Integration

GitHub Action

semver-checks ships a reusable composite action. The most ergonomic setup compares the published `latest` release against the PR's working tree, so it needs no git tags and posts inline annotations on the diff:

name: SemVer Check

on: pull_request: branches: [main]

jobs: semver-checks: runs-on: ubuntu-latest steps:

• uses: actions/checkout@v4
• uses: actions/setup-node@v4 with: node-version: "22"
• run: npm ci

• uses: kyungseopk1m/semver-checks@v0.17.0 with: old: "your-package@latest" # the published version to compare against format: "github" # inline ::error:: / ::warning:: annotations strict: "true" # fail the PR on a confident (proven) breaking change

A full example lives in examples/github-actions.yml.

On a release pull request

Does the bump this release declares cover what its API surface did? @clerk/break-check and semvet also score the declared bump from the two package.json versions; reading it from .changeset files is what is specific here. declared: auto reads the bump from `.changeset