@williamthorsen/release-kit 18.1.1 → 18.3.0

package/docs/releasing.md

@@ -31,13 +31,14 @@ The workflows are managed files: release-kit renders them, and a change made by
 
 Runs release preparation with automatic workspace discovery.
 
-`--only` names the release targets from which the release starts, by target name: a workspace's directory name (e.g., `arrays`, `release-kit`) unless a [`releases`](configuration.md#releases) entry renames it, or a `releases` composite's name. A named composite releases from its own window, whether or not the run includes its members; a run narrowed by `--only` skips every composite that it doesn't name. The run also releases every workspace that depends on one of them, directly or transitively: A dependent with commits of its own releases at its own bump, and one without releases at a propagated patch bump, so that it publishes against the new version. Workspaces outside that set are left out of the run.
+`--only` names the release targets from which the release starts, by target name: a workspace's directory name (e.g., `arrays`, `release-kit`) unless a [`releases`](configuration.md#releases) entry renames it, or a `releases` composite's name. A named composite releases from its own window, whether or not the run includes its members; a run narrowed by `--only` skips every composite that it doesn't name. The run also releases every workspace that depends on one of them, directly or transitively: A dependent whose commits call for a bump releases at its own bump, and one whose commits don't releases at a propagated patch bump, so that it publishes against the new version; its changelog entry lists its own items, if any, with the dependencies. Workspaces outside that set are left out of the run.
 
 `prepare` reads each target's history once and builds the changelog items of its unreleased commits. The bump is the highest level that those items call for, under [`versionPatterns`](configuration.md#versionpatterns), so the bump and the changelog describe the same release: A `feat` entry in a [change-record block](changelogs.md#change-record-blocks) bumps minor under a `docs:` title, and a breaking item bumps major.
 
 - A commit that doesn't yield an item doesn't bump anything: one without a ticket-ID prefix, one of a type excluded from the changelog (such as `fmt`), and one whose change-record entries are all undeclared or excluded.
 - A `BREAKING CHANGE:` footer doesn't raise a major bump. Only a subject's `!` and an entry's `breaking: true` mark an item breaking; on a type whose policy forbids `!`, the footer is reported as a [policy violation](work-types.md#policy-enforcement).
-- A target whose commits don't yield an item is skipped. The prepare report lists the commits that could not be parsed and the change-record diagnostics, skipped targets included.
+- An item of a type that [`versionPatterns.none`](configuration.md#versionpatterns) lists, such as `tests` or `ci` by default, doesn't bump anything unless it is breaking.
+- A target whose items don't call for a bump is skipped, and so is one whose commits don't yield an item. The prepare report lists the commits that could not be parsed and the change-record diagnostics, skipped targets included.
 
 `--bump` and `--force` are orthogonal in every mode, single-package included: `--bump` is purely a level chooser; `--force` is purely a release trigger. Examples:
 

package/docs/work-types.md

@@ -28,6 +28,8 @@ release-kit reads the taxonomy from `CANONICAL_TAXONOMY` in [`@williamthorsen/ch
 - **`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`.
 
+Tiers decide the audience, not the bump: [`versionPatterns`](configuration.md#versionpatterns) decides which types bump and which don't, and by default some `internal`- and `process`-tier types bump patch while others don't bump at all.
+
 Section render order is **tier order (`public` → `internal` → `process`), then row order within tier**. It comes from the declaration order of `CANONICAL_TAXONOMY`: `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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@williamthorsen/release-kit",
-  "version": "18.1.1",
+  "version": "18.3.0",
   "description": "Version-bumping and changelog-generation toolkit for release workflows",
   "keywords": [
     "changelog",
@@ -53,7 +53,7 @@
   "dependencies": {
     "@williamthorsen/change-grammar": "0.4.1",
     "@williamthorsen/nmr-core": "0.16.2",
-    "@williamthorsen/toolbelt.errors": "0.9.1",
+    "@williamthorsen/toolbelt.errors": "0.10.1",
     "json-stringify-pretty-compact": "4.0.0",
     "semver": "7.8.6",
     "yaml": "2.9.1",
@@ -61,13 +61,13 @@
   },
   "devDependencies": {
     "@types/semver": "7.8.0",
-    "@williamthorsen/nmr": "2.0.3",
-    "@williamthorsen/toolbelt.filesystem": "0.10.1",
-    "@williamthorsen/toolbelt.testing": "0.8.1",
-    "@williamthorsen/toolbelt.vitest": "0.13.3",
+    "@williamthorsen/nmr": "2.2.2",
+    "@williamthorsen/toolbelt.filesystem": "0.11.0",
+    "@williamthorsen/toolbelt.testing": "0.8.3",
+    "@williamthorsen/toolbelt.vitest": "0.13.5",
     "actionlint": "2.0.6",
     "esbuild": "0.28.2",
-    "readyup": "0.45.1",
+    "readyup": "0.46.2",
     "smol-toml": "1.9.1",
     "vitest": "5.1.0"
   },

package/presets/labels/common.yaml

@@ -44,6 +44,20 @@
   color: cfd3d7
   aliases: ['priority:low']
 
+# Effort
+- name: 'effort:1'
+  color: dbe9ff
+- name: 'effort:2'
+  color: b9d4ff
+- name: 'effort:3'
+  color: 8fb8fb
+- name: 'effort:5'
+  color: 5b93f0
+- name: 'effort:8'
+  color: '3470e0'
+- name: 'effort:13'
+  color: 1d4ed8
+
 # Status
 - name: 'status:blocked'
   color: b83280

package/dist/esm/sync-labels/retiredConfig.d.ts

@@ -1,11 +0,0 @@
-/** Path of the retired standalone sync-labels config file. */
-export declare const RETIRED_SYNC_LABELS_CONFIG_PATH = ".config/sync-labels.config.ts";
-/**
- * Reports an actionable migration error when the retired standalone config file is present.
- *
- * Returns `true` when the file exists, in which case the caller must abort. The check is
- * unconditional on config content: File presence alone triggers it, so a half-migrated
- * repo cannot silently lose its custom labels. `configPath` names the config into which the
- * message directs the labels.
- */
-export declare function checkRetiredSyncLabelsConfig(configPath?: string): boolean;

package/dist/esm/sync-labels/retiredConfig.js

@@ -1,12 +0,0 @@
-import { existsSync } from 'node:fs';
-import { reportError } from '@williamthorsen/nmr-core';
-import { BIN } from "../bin.js";
-import { CONFIG_FILE_PATH } from "../loadConfig.js";
-export const RETIRED_SYNC_LABELS_CONFIG_PATH = '.config/sync-labels.config.ts';
-export function checkRetiredSyncLabelsConfig(configPath = CONFIG_FILE_PATH) {
-    if (!existsSync(RETIRED_SYNC_LABELS_CONFIG_PATH)) {
-        return false;
-    }
-    reportError(BIN, `${RETIRED_SYNC_LABELS_CONFIG_PATH} is no longer read. Move its labels into the \`repoLabels\` block of ${configPath} (presets move to \`repoLabels.extends\`; each label becomes a \`'name': { color, description }\` entry under \`repoLabels.labels\`), then delete the file.`);
-    return true;
-}