@hyperfrontend/versioning§

_{Nobody picks the version here. The breaking marker in the header is what makes this release a major, and everything on the right is derived from that one line.}

Versioning library with changelog parsing, conventional commits, and semver flow orchestration.

• 👉 See roadmap

What is @hyperfrontend/versioning?

@hyperfrontend/versioning provides a comprehensive toolkit for managing software versioning in JavaScript/TypeScript projects. The library is built on a purely functional architecture with factory functions, immutable data structures, and composable operations.

Key Features

Why Use @hyperfrontend/versioning?

Type-Safe Changelog Manipulation

Working with CHANGELOG.md files programmatically typically involves fragile string manipulation. This library parses changelogs into fully typed data structures with factory functions for creating entries, sections, and items. Modify changelog content with confidence using immutable operations and round-trip safely back to markdown.

Unified Versioning Primitives

Version management requires coordinating semver parsing, commit analysis, changelog generation, and registry queries. This library provides all these primitives in one cohesive package with consistent APIs. Query npm for published versions, parse commit history, calculate version bumps, and generate changelog entries, all composable into custom release workflows.

Zero-Dependency CI Integration

Designed for automated pipelines where minimal attack surface matters. Zero external runtime dependencies and state-machine parsing ensure predictable performance on any input. All parsers enforce input length limits to prevent resource exhaustion.

One-Stop Commit Toolchain

The interactive cz and validator cl bins cover the same ground as commitizen + cz-conventional-changelog + @commitlint/cli, in one package, without patch-package workarounds, with a config-driven session (commit.config.{js,mjs,cjs}), a live 72-char header countdown, and scope choices derived from staged files. Acknowledgment to those projects: they shaped the conventions this library now implements natively.

Installation

npm install @hyperfrontend/versioning

Quick Start

Parsing a Changelog

import { parseChangelog } from '@hyperfrontend/versioning'
import fs from 'fs'

// Parse existing changelog content
const content = fs.readFileSync('CHANGELOG.md', 'utf-8')
const changelog = parseChangelog(content)

// Access entries
for (const entry of changelog.entries) {
  console.log(`Version ${entry.version} - ${entry.date}`)
  for (const section of entry.sections) {
    console.log(`  ${section.heading}: ${section.items.length} changes`)
  }
}

// Access metadata
// Formats: 'keep-a-changelog' (https://keepachangelog.com), 'conventional', etc.
console.log(changelog.metadata.format)

Parsing Conventional Commits

import { parseConventionalCommit } from '@hyperfrontend/versioning'

const commit = parseConventionalCommit('feat(api): add user authentication')

console.log(commit.type) // 'feat'
console.log(commit.scope) // ['api'], an array because `feat(a,b): x` names two
console.log(commit.subject) // 'add user authentication'
console.log(commit.breaking) // false

Checking for Breaking Changes

import { parseConventionalCommit } from '@hyperfrontend/versioning'

// Breaking change via !
const commit1 = parseConventionalCommit('feat(api)!: remove deprecated endpoint')
console.log(commit1.breaking) // true

// Breaking change via footer
const commit2 = parseConventionalCommit(\`fix: update API response format

BREAKING CHANGE: Response structure has changed\`)
console.log(commit2.breaking) // true
console.log(commit2.breakingDescription) // 'Response structure has changed'

API Overview

The package publishes one subpath per concern, and the name of the import is the job it does. commits parses, validates, classifies and authors conventional commit messages. changelog reads and writes CHANGELOG.md. semver parses, compares and increments versions and ranges. git, registry and workspace cover the three things a release has to ask the world outside the process: the repository, the npm registry, and the packages on disk. repository turns a remote URL into the compare links a changelog entry carries. flow composes the rest into a release. The root entry re-exports all of them.

parseConventionalCommit is where most work starts: hand it the raw message and it returns a ConventionalCommit carrying type, subject, breaking, the parsed footers and a scope that is a readonly string[] rather than a string, because feat(a,b): x names two. Its type and breaking go to getSemverBump, which answers major, minor, patch or none, and that answer plus a parsed version goes to increment. All three are pure functions over plain data.

parseChangelog turns a CHANGELOG.md into an addressable tree of entries, sections and items, and serializeChangelog writes that tree back to markdown, so a file read and rewritten unedited comes back as itself. Those parsers, and the commit parsers beside them, are hand-written character state machines rather than regular expressions, and each refuses oversized input before it begins, which is why no pathological changelog can stall a release job.

Two bins ship alongside the API, and neither asks you to import anything: npx cz runs the interactive session that authors a conventional commit, and npx cl <path> validates one message from a commit-msg hook. For unattended releases, createConventionalFlow assembles the ordered steps (fetch the published version, analyse commits, calculate the bump, generate the changelog entry, update package.json, write, commit, tag) and executeFlow runs them against a virtual file system, so a dry run reports the whole diff without touching disk.

Every model, option, step and outcome type is in the API reference.

Compatibility

Security

All parsers use state-machine tokenization with O(n) complexity and enforce input length limits (commit messages: 10KB, changelog files: 1MB) to prevent resource exhaustion. Character-by-character parsing eliminates regex-based vulnerabilities.