@williamthorsen/release-kit 10.9.0 → 12.0.0

package/docs/work-types.md

@@ -28,7 +28,11 @@ release-kit bundles a copy of the codeassembly canonical taxonomy in `packages/r
 - **`internal`** — dev-only. `internal`-tier sections appear in dev changelogs but not in public-facing release notes.
 - **`process`** — dev-only. Same audience treatment as `internal`.
 
-Section render order is **tier order (`public` → `internal` → `process`), then row order within tier**. The bundled `cliff.toml.template` encodes this order via hidden `<!-- NN -->` HTML-comment prefixes on each parser's `group` value; tera's `group_by` filter sorts groups lexicographically (now monotonic by row number), and the body template's `striptags` filter erases the prefix from rendered headings.
+Section render order is **tier order (`public` → `internal` → `process`), then row order within tier**. It comes from the declaration order of `work-types.json`: `CANONICAL_SECTION_ORDER` in `buildChangelogEntries.ts` indexes each header by its row, and `transformReleases` sorts a release's sections by that index whatever order the commits arrived in.
+
+## Subject forms
+
+`classifyChangelogCommit` resolves a commit's type through `parseCommitMessage`, so a subject reaches its section under any form that parser accepts: `type:`, `scope|type:`, and the conventional-commit `type(scope):`. The type is matched case-insensitively, so `Feat:` and `FEAT:` resolve like `feat:`. The ticket-ID prefix is still required, and an alias resolves before the section is chosen. A commit whose [change-record block](changelogs.md#change-record-blocks) records entries takes its sections from the entries' types instead of from its subject.
 
 ## `utility` alias
 
@@ -44,11 +48,11 @@ Each work-type carries a `breakingPolicy` value:
 
 ### Policy enforcement
 
-`parseCommitMessage` enforces the `!` policy at release time and treats a violation as a warning. Commits already in the log cannot be rewritten, so a policy-violating commit is parsed using its canonical type with `breaking: false` (the `!` is dropped from the parse) and an `onPolicyViolation` callback fires. Callers (`decideRelease` etc.) can collect these warnings and surface them in the release report. A single legacy `internal!` in a year-old log does not block releases.
+`parseCommitMessage` enforces the `!` policy at release time and treats a violation as a warning. Commits already in the log cannot be rewritten, so a policy-violating commit is parsed using its canonical type with `breaking: false` (the `!` is dropped from the parse) and an `onPolicyViolation` callback fires. `readReleaseHistory` collects these warnings while it builds the items of the unreleased window, and the release report lists them. A single legacy `internal!` in a year-old log does not block releases.
 
-A `BREAKING CHANGE:` body footer on a `forbidden`-policy type triggers the same warning path as the prefix `!` does: A type that cannot be breaking is parsed as non-breaking whichever surface carries the signal.
+A `BREAKING CHANGE:` body footer on a `forbidden`-policy type triggers the same warning path as the prefix `!` does: A type that cannot be breaking is parsed as non-breaking whichever surface carries the signal. The warning is all that a footer triggers; it raises no bump (see [`🚨 **Breaking:**` bullet marker](#-breaking-bullet-marker)).
 
-The release-prepare orchestrators (`releasePrepare`, `releasePrepareMono`, `releasePrepareProject`) apply `DEFAULT_BREAKING_POLICIES` automatically. Violations encountered while parsing each workspace's or project's commit window are collected onto the corresponding result's `policyViolations` field and rendered under the section in the prepare report:
+The release-prepare orchestrators (`releasePrepare`, `releasePrepareMono`, `releasePrepareProject`) apply `DEFAULT_BREAKING_POLICIES` automatically. Violations in the titles and change-record entries of each workspace's or project's unreleased window are collected onto the corresponding result's `policyViolations` field, on a skipped result as on a released one, and rendered under the section in the prepare report:
 
 ```
 arrays
@@ -73,9 +77,9 @@ The marker agrees with the version bump:
 
 - A `forbidden`-policy type carrying `!`, such as `refactor!`, gets no marker, just as its `!` raises no bump; the prepare report lists it as a policy violation. An [editorial override](editorial-overrides.md) that sets `breaking: true` restores the marker for one entry.
 - The configured `breakingPolicies` map, `{}` included, decides which types permit the marker.
-- A commit whose type the parser cannot resolve has no policy, so its `!` prefix alone decides.
+- A commit whose type the parser cannot resolve reaches no changelog at all, so no marker question arises.
 
-A `BREAKING CHANGE:` body footer on its own does **not** retroactively mark a changelog item as breaking, even on a type whose policy permits `!`; the changelog signal is tied to the commit prefix. This avoids surprise breaking-marker appearances for older commits written under earlier conventions.
+A `BREAKING CHANGE:` body footer on its own does **not** retroactively mark a changelog item as breaking, even on a type whose policy permits `!`; the changelog signal is tied to the commit prefix. This avoids surprise breaking-marker appearances for older commits written under earlier conventions. The bump follows the items, so a footer raises no major bump either: A consumer that marks breaking changes with the footer alone gets the bump of the commit's type.
 
 The emoji and label of this marker are sourced from the `markers.breaking` entry in `work-types.json` (see [Section markers](#section-markers)) so consumers that render their own breaking-changes section draw from the same SSOT.
 
@@ -95,13 +99,13 @@ Entries store plain text only — the SSOT is format-agnostic, so consumers appl
 
 ## `fmt`
 
-`fmt:` commits are recognized by `parseCommitMessage` (they contribute to a patch bump) but `fmt` carries `excludedFromChangelog: true`. The bundled `cliff.toml.template` skips `fmt:` commits at the parser level, so they never appear in `CHANGELOG.md`, `changelog.json`, or release notes. The label and emoji are present in `work-types.json` for schema parity with the codeassembly upstream but never render.
+`fmt:` commits are recognized by `parseCommitMessage`, but `fmt` carries `excludedFromChangelog: true`, which `DEFAULT_WORK_TYPES` carries onto its `WorkTypeConfig`. `classifyChangelogCommit` excludes a commit whose type sets the flag, so a `fmt:` commit never appears in `CHANGELOG.md`, `changelog.json`, or release notes. It yields no item, so it raises no bump, and the release report does not list it as unparseable. The label and emoji are present in `work-types.json` for schema parity with the codeassembly upstream but never render.
 
 ## Custom work types
 
-Work types from your config are merged with these defaults by key — your entries override or extend, they don't replace the full set. Release-notes sections are rendered in the declaration order of the merged work-types record, with any unknown titles trailing the known ones.
+Work types from a config are merged with these defaults by key: a consumer entry overrides or extends, it does not replace the full set. `classifyChangelogCommit` reads the merged record, so an added type reaches the changelog under the `header` it declares, and an entry setting `excludedFromChangelog: true` keeps its commits out of the changelog and the bump. Release-notes sections are rendered in the declaration order of the merged work-types record, with any unknown titles trailing the known ones.
 
-The default `devOnlySections` (excluded from public release notes but still written to `CHANGELOG.md`) are derived from the `internal` and `process` tiers (excluding `fmt`). Override via `changelogJson.devOnlySections` in your config; matching is decorator-tolerant, so a bare-name override like `['Internal features']` keeps working against the emoji-prefixed and prefix-decorated default titles.
+The default `devOnlySections` (excluded from public release notes but still written to `CHANGELOG.md`) are derived from the `internal` and `process` tiers (excluding `fmt`). Override via `changelogJson.devOnlySections`; matching is decorator-tolerant, so a bare-name override like `['Internal features']` keeps working against the emoji-prefixed default titles.
 
 ## Maintaining the bundled taxonomy
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@williamthorsen/release-kit",
-  "version": "10.9.0",
+  "version": "12.0.0",
   "description": "Version-bumping and changelog-generation toolkit for release workflows",
   "keywords": [
     "changelog",
@@ -43,7 +43,6 @@
     ".readyup/manifest.json",
     "CHANGELOG.md",
     "bin",
-    "cliff.toml.template",
     "dist/*",
     "docs",
     "!docs/*.v*.md",
@@ -51,13 +50,12 @@
     "schemas/**"
   ],
   "dependencies": {
-    "@williamthorsen/nmr-core": "0.12.0",
+    "@williamthorsen/nmr-core": "0.13.0",
     "@williamthorsen/toolbelt.errors": "0.8.1",
-    "glob": "13.0.6",
     "json-stringify-pretty-compact": "4.0.0",
     "semver": "7.8.5",
-    "yaml": "2.9.0",
-    "zod": "4.6.2"
+    "yaml": "2.9.1",
+    "zod": "4.6.5"
   },
   "devDependencies": {
     "@types/semver": "7.8.0",
@@ -69,7 +67,7 @@
     "vitest": "4.1.11"
   },
   "engines": {
-    "node": ">=24"
+    "node": ">=24.16.0"
   },
   "publishConfig": {
     "access": "public",

package/schemas/changelog-overrides.json

@@ -0,0 +1,39 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "changelog-overrides",
+  "description": "Editorial overrides that release-kit applies to generated changelog items. Each key is a lowercase hex commit hash or prefix, which targets every item of the commit, optionally followed by `:<n>`, which targets the item derived from the commit's `n`th change-record entry.",
+  "type": "object",
+  "additionalProperties": false,
+  "properties": {
+    "$schema": {
+      "type": "string",
+      "description": "JSON Schema reference for editor support."
+    }
+  },
+  "patternProperties": {
+    "^[0-9a-f]+(:[1-9][0-9]*)?$": {
+      "type": "object",
+      "description": "Override for the items that the key targets. At least one field must be set.",
+      "additionalProperties": false,
+      "minProperties": 1,
+      "properties": {
+        "audience": {
+          "enum": ["all", "dev", "skip"],
+          "description": "`skip` removes the items. `all` and `dev` are reserved and not yet supported."
+        },
+        "description": {
+          "type": "string",
+          "description": "Replaces the item's headline."
+        },
+        "body": {
+          "type": "string",
+          "description": "Replaces the item's body."
+        },
+        "breaking": {
+          "type": "boolean",
+          "description": "Sets whether the item is marked as breaking."
+        }
+      }
+    }
+  }
+}

package/cliff.toml.template

@@ -1,65 +0,0 @@
-# git-cliff configuration
-# Generates changelogs from conventional-ish commit messages.
-#
-# Commit format: [ticket-prefix ]scope|type[!]: description [#PR]
-# Examples:
-#   #19 rdy|feat: Add utility functions for common check patterns (#26)
-#   AFG-42 panel|fix: Fix button layout (#73)
-#   ## feat: Quick utility added during interactive session
-#
-# Only ticketed commits (leading #NN, PROJ-NN, or ##) are included.
-# Unticketed maintenance commits (deps upgrades, tooling tweaks) are skipped.
-# Use ## as a synthetic ticket prefix for ad-hoc commits that belong in the changelog.
-#
-# Section order: each `group` value carries a hidden `<!-- NN -->` HTML-comment
-# prefix encoding the canonical row position. tera's `group_by` filter sorts
-# groups lexicographically by string, and the body template's `striptags`
-# filter erases the comment from the rendered heading. Numbering is per
-# unique group (not per parser entry) — all parsers routing to the same group
-# share the same prefix.
-
-# Markdown rendering is handled in-process by `renderChangelogMarkdown.ts`. cliff is invoked
-# only for `--context` JSON output (see `buildChangelogEntries.ts`), so no `[changelog]` block
-# is needed. The `[git].commit_parsers` section below remains load-bearing for group
-# assignment in the `--context` payload.
-
-[git]
-conventional_commits = false
-filter_unconventional = false
-split_commits = false
-commit_preprocessors = []
-# Require a ticket-ID prefix for inclusion.
-# Supported prefixes: "#123 ", "#123-1 ", "#123.1 ", "TOOL-123 ", "## "
-commit_parsers = [
-  { message = "^release:", skip = true },
-  { message = "^Merge", skip = true },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?feat(!)?:", group = "<!-- 01 -->🎉 Features" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?feature(!)?:", group = "<!-- 01 -->🎉 Features" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?drop(!)?:", group = "<!-- 02 -->🪦 Removed" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?deprecate(!)?:", group = "<!-- 03 -->🗑️ Deprecated" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?fix(!)?:", group = "<!-- 04 -->🐛 Bug fixes" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?bugfix(!)?:", group = "<!-- 04 -->🐛 Bug fixes" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?sec(!)?:", group = "<!-- 05 -->🔒 Security" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?security(!)?:", group = "<!-- 05 -->🔒 Security" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?perf(!)?:", group = "<!-- 06 -->⚡ Performance" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?performance(!)?:", group = "<!-- 06 -->⚡ Performance" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?internal(!)?:", group = "<!-- 07 -->🏗️ Internal features" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?utility(!)?:", group = "<!-- 07 -->🏗️ Internal features" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?refactor(!)?:", group = "<!-- 08 -->♻️ Refactoring" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?tests?(!)?:", group = "<!-- 09 -->🧪 Tests" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?tooling(!)?:", group = "<!-- 10 -->⚙️ Tooling" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?ci(!)?:", group = "<!-- 11 -->👷 CI" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?deps?(!)?:", group = "<!-- 12 -->📦 Dependencies" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?ai(!)?:", group = "<!-- 13 -->🤖 Agentic support" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?docs?(!)?:", group = "<!-- 14 -->📚 Documentation" },
-  { message = "^(\\#\\d+([.\\-]\\d+)?|\\#\\#|[A-Z]+-\\d+)\\s+([^|]+\\|)?fmt(!)?:", skip = true },
-  # Skip unticketed commits (maintenance, deps, initial scaffolding, etc.)
-  { message = ".*", skip = true },
-]
-protect_breaking_commits = false
-filter_commits = true
-tag_pattern = "v[0-9].*"
-skip_tags = ""
-ignore_tags = ""
-topo_order = false
-sort_commits = "oldest"

package/dist/esm/collectPolicyViolations.d.ts

@@ -1,15 +0,0 @@
-import type { PolicyViolationHandler } from './parseCommitMessage.js';
-import type { PolicyViolation } from './types.js';
-/**
- * Build a fresh `policyViolations` accumulator paired with the `onPolicyViolation` callback
- * that pushes structured entries into it.
- *
- * Used by all three release-prepare orchestrators (`releasePrepare`, `releasePrepareMono`,
- * `releasePrepareProject`) to collect parser-side `!`-policy violations into a result-attachable
- * array. Centralizing the callback shape keeps the `commitSubject` extraction rule (`firstLine
- * post-split`) consistent across orchestrators.
- */
-export declare function createPolicyViolationCollector(): {
-    violations: PolicyViolation[];
-    onPolicyViolation: PolicyViolationHandler;
-};

package/dist/esm/collectPolicyViolations.js

@@ -1,12 +0,0 @@
-export function createPolicyViolationCollector() {
-    const violations = [];
-    const onPolicyViolation = (commit, type, surface) => {
-        violations.push({
-            commitHash: commit.hash,
-            commitSubject: commit.message.split('\n', 1)[0] ?? '',
-            type,
-            surface,
-        });
-    };
-    return { violations, onPolicyViolation };
-}

package/dist/esm/determineBumpFromCommits.d.ts

@@ -1,17 +0,0 @@
-import { type PolicyViolationHandler } from './parseCommitMessage.js';
-import type { Commit, ReleaseType, VersionPatterns, WorkTypeConfig } from './types.js';
-/** Aggregate result of parsing commits and determining the bump type. */
-export interface BumpDetermination {
-    releaseType: ReleaseType | undefined;
-    parsedCommitCount: number;
-    unparseableCommits: Commit[] | undefined;
-}
-/** Optional configuration for parser-policy plumbing. */
-export interface DetermineBumpOptions {
-    /** Per-canonical-type breaking-policy lookup (drives `!` policy enforcement). */
-    breakingPolicies?: Record<string, 'forbidden' | 'optional' | 'required'>;
-    /** Receives policy-violation notifications from `parseCommitMessage`. */
-    onPolicyViolation?: PolicyViolationHandler;
-}
-/** Parse commits, determine bump type, and apply patch floor when commits exist but none parsed. */
-export declare function determineBumpFromCommits(commits: Commit[], workTypes: Record<string, WorkTypeConfig>, versionPatterns: VersionPatterns, scopeAliases: Record<string, string> | undefined, options?: DetermineBumpOptions): BumpDetermination;

package/dist/esm/determineBumpFromCommits.js

@@ -1,28 +0,0 @@
-import { determineBumpType } from "./determineBumpType.js";
-import { parseCommitMessage, } from "./parseCommitMessage.js";
-export function determineBumpFromCommits(commits, workTypes, versionPatterns, scopeAliases, options) {
-    const parseOptions = {
-        ...(options?.breakingPolicies !== undefined && { breakingPolicies: options.breakingPolicies }),
-        ...(options?.onPolicyViolation !== undefined && { onPolicyViolation: options.onPolicyViolation }),
-    };
-    const parsedCommits = [];
-    const unparseable = [];
-    for (const commit of commits) {
-        const parsed = parseCommitMessage(commit.message, commit.hash, workTypes, scopeAliases, parseOptions);
-        if (parsed === undefined) {
-            unparseable.push(commit);
-        }
-        else {
-            parsedCommits.push(parsed);
-        }
-    }
-    let releaseType = determineBumpType(parsedCommits, workTypes, versionPatterns);
-    if (releaseType === undefined && commits.length > 0) {
-        releaseType = 'patch';
-    }
-    return {
-        releaseType,
-        parsedCommitCount: parsedCommits.length,
-        unparseableCommits: unparseable.length > 0 ? unparseable : undefined,
-    };
-}

package/dist/esm/getCommitsSinceTarget.d.ts

@@ -1,21 +0,0 @@
-import type { Commit } from './types.js';
-/**
- * Gets commits since the latest baseline tag matching any of the given prefixes.
- *
- * Uses `git log` to retrieve commit messages and hashes between the closest reachable
- * baseline tag and HEAD. When no tag matches any prefix, all commits reachable from HEAD
- * are returned.
- *
- * Callers must pass at least one prefix; the single-prefix case is the common one (the
- * workspace's derived prefix). Multiple prefixes are used to include historical tag prefixes
- * from `legacyIdentities`.
- *
- * @param tagPrefixes - Tag prefixes to search as a union (e.g., `['core-v', 'old-core-v']`).
- * @param paths - Optional glob patterns to filter commits by path (appended after `--` in `git log`).
- *   Path patterns use POSIX-style forward slashes; Windows compatibility is not guaranteed.
- * @returns An object with the found tag (if any) and the list of commits.
- */
-export declare function getCommitsSinceTarget(tagPrefixes: readonly string[], paths?: string[]): {
-    tag: string | undefined;
-    commits: Commit[];
-};

package/dist/esm/getCommitsSinceTarget.js

@@ -1,66 +0,0 @@
-import { execFileSync } from 'node:child_process';
-import { GIT_OUTPUT_LIMIT } from '@williamthorsen/nmr-core';
-import { chainError } from '@williamthorsen/toolbelt.errors/candidate';
-const FIELD_SEPARATOR = '\u{1F}';
-function isNoTagError(err) {
-    return typeof err === 'object' && err !== null && 'status' in err && err.status === 128;
-}
-function findLatestTag(tagPrefixes) {
-    if (tagPrefixes.length === 0) {
-        throw new Error('findLatestTag: tagPrefixes must contain at least one entry');
-    }
-    const matchArgs = tagPrefixes.map((prefix) => `--match=${prefix}*`);
-    try {
-        const tagResult = execFileSync('git', ['describe', '--tags', '--abbrev=0', ...matchArgs], {
-            encoding: 'utf8',
-            maxBuffer: GIT_OUTPUT_LIMIT,
-            stdio: ['pipe', 'pipe', 'pipe'],
-        }).trim();
-        return tagResult || undefined;
-    }
-    catch (error) {
-        if (isNoTagError(error)) {
-            return undefined;
-        }
-        throw chainError(`Failed to run 'git describe'`, error);
-    }
-}
-const RELEASE_COMMIT_PREFIX = 'release:';
-function parseLogOutput(logOutput) {
-    const commits = [];
-    for (const line of logOutput.split('\n')) {
-        const trimmedLine = line.trim();
-        if (trimmedLine === '') {
-            continue;
-        }
-        const [message, hash] = trimmedLine.split(FIELD_SEPARATOR);
-        if (message !== undefined && hash !== undefined && !message.startsWith(RELEASE_COMMIT_PREFIX)) {
-            commits.push({ message, hash });
-        }
-    }
-    return commits;
-}
-export function getCommitsSinceTarget(tagPrefixes, paths) {
-    const tag = findLatestTag(tagPrefixes);
-    const range = tag === undefined ? 'HEAD' : `${tag}..HEAD`;
-    const format = `%s${FIELD_SEPARATOR}%H`;
-    const args = ['log', range, `--pretty=format:${format}`];
-    if (paths !== undefined && paths.length > 0) {
-        args.push('--', ...paths);
-    }
-    let logOutput;
-    try {
-        logOutput = execFileSync('git', args, {
-            encoding: 'utf8',
-            maxBuffer: GIT_OUTPUT_LIMIT,
-            stdio: ['pipe', 'pipe', 'pipe'],
-        }).trim();
-    }
-    catch (error) {
-        throw chainError(`Failed to run 'git log' for range '${range}'`, error);
-    }
-    if (logOutput === '') {
-        return { tag, commits: [] };
-    }
-    return { tag, commits: parseLogOutput(logOutput) };
-}

package/dist/esm/resolveCliffConfigPath.d.ts

@@ -1,11 +0,0 @@
-/**
- * Resolve the git-cliff configuration file path.
- *
- * Checks candidates in order: explicit `cliffConfigPath` -> `.config/git-cliff.toml` ->
- * `cliff.toml` -> bundled `cliff.toml.template`. Returns the first path that exists,
- * or throws if even the bundled template cannot be found.
- *
- * When an explicit `cliffConfigPath` is provided, it is returned as-is without checking
- * existence, preserving current behavior (git-cliff reports the error if the file is missing).
- */
-export declare function resolveCliffConfigPath(cliffConfigPath: string | undefined, metaUrl: string): string;

package/dist/esm/resolveCliffConfigPath.js

@@ -1,20 +0,0 @@
-import { existsSync } from 'node:fs';
-import { resolve } from 'node:path';
-import { findPackageRoot } from '@williamthorsen/nmr-core';
-export function resolveCliffConfigPath(cliffConfigPath, metaUrl) {
-    if (cliffConfigPath !== undefined) {
-        return cliffConfigPath;
-    }
-    const candidates = ['.config/git-cliff.toml', 'cliff.toml'];
-    for (const candidate of candidates) {
-        if (existsSync(candidate)) {
-            return candidate;
-        }
-    }
-    const root = findPackageRoot(metaUrl);
-    const bundledPath = resolve(root, 'cliff.toml.template');
-    if (existsSync(bundledPath)) {
-        return bundledPath;
-    }
-    throw new Error(`Could not resolve a git-cliff config file. Searched: ${candidates.join(', ')}, and bundled template at ${bundledPath}`);
-}

package/dist/esm/runGitCliff.d.ts

@@ -1,38 +0,0 @@
-/**
- * The exact `git-cliff` version every invocation resolves.
- *
- * npm's `git-cliff` trails the upstream release, so this pin normally sits behind the newest version cliff
- * itself reports. Bumping it is an edit to this line, once npm publishes the version you want.
- */
-export declare const GIT_CLIFF_VERSION = "2.13.1";
-/** The npx arguments that precede the cliff args at every invocation, and that the dry-run report renders. */
-export declare const GIT_CLIFF_NPX_ARGS: readonly string[];
-/**
- * Invokes `git-cliff` via `npx` and returns the output it produced.
- *
- * Single entry point for `git-cliff` invocations from `release-kit`. Owns three pieces of shared lifecycle
- * that would otherwise duplicate (and silently drift) across call sites: the npx flags, the spawned-process
- * environment, and the temp dir holding both the `.template`→`.toml` config copy and cliff's output file.
- *
- * Output is routed through `--output` to a temp file and read back. `--context` emits a workspace's
- * entire matching tag history on every run, so its size grows without bound with the repo;
- * a file accommodates that, while a pipe is bounded by `maxBuffer`.
- *
- * The npx spec names an exact version, which leaves npm no staleness to check, so `--prefer-offline` skips the
- * per-call registry revalidation round-trip (~2.5 s per invocation on a warm cache) without stranding the run
- * on whatever the cache happens to hold.
- *
- * Two env entries are set for the child. `npm_config_progress=false` suppresses npx's animated stderr spinner,
- * which otherwise renders as a transient flicker. `RUST_LOG=warn` drops cliff's INFO lines, among them the
- * crates.io update notice it emits on every invocation while npm trails upstream, and leaves warnings and errors
- * in place; an inherited `RUST_LOG` wins, so raising the level for debugging still works.
- *
- * The helper injects `--config <path>` and `--output <path>` itself — callers must NOT include either in `cliffArgs`.
- * `--output` is appended last so a caller that passes one anyway cannot redirect the output the helper then reads.
- * The caller is responsible for resolving the cliff config path (via `resolveCliffConfigPath`) before calling,
- * since the resolution depends on the caller's `import.meta.url`.
- *
- * Errors from `execFileSync` are not caught: callers wrap with site-specific messages.
- * The temp-dir cleanup runs in a `finally` so it still happens on throw.
- */
-export declare function runGitCliff(cliffConfigPath: string, cliffArgs: readonly string[]): string;

package/dist/esm/runGitCliff.js

@@ -1,25 +0,0 @@
-import { execFileSync } from 'node:child_process';
-import { copyFileSync, mkdtempSync, readFileSync, rmSync } from 'node:fs';
-import { tmpdir } from 'node:os';
-import { join } from 'node:path';
-export const GIT_CLIFF_VERSION = '2.13.1';
-export const GIT_CLIFF_NPX_ARGS = ['--prefer-offline', '--yes', `git-cliff@${GIT_CLIFF_VERSION}`];
-export function runGitCliff(cliffConfigPath, cliffArgs) {
-    const tempDir = mkdtempSync(join(tmpdir(), 'cliff-'));
-    try {
-        let configPath = cliffConfigPath;
-        if (cliffConfigPath.endsWith('.template')) {
-            configPath = join(tempDir, 'cliff.toml');
-            copyFileSync(cliffConfigPath, configPath);
-        }
-        const outputPath = join(tempDir, 'output.json');
-        execFileSync('npx', [...GIT_CLIFF_NPX_ARGS, '--config', configPath, ...cliffArgs, '--output', outputPath], {
-            stdio: ['ignore', 'ignore', 'inherit'],
-            env: { ...process.env, npm_config_progress: 'false', RUST_LOG: process.env['RUST_LOG'] ?? 'warn' },
-        });
-        return readFileSync(outputPath, 'utf8');
-    }
-    finally {
-        rmSync(tempDir, { recursive: true, force: true });
-    }
-}