@oakoss/oakum 0.9.3 → 0.10.0

package/CHANGELOG.md

@@ -1,5 +1,35 @@
 # Changelog
 
+## 0.10.0 (2026-11-11)
+
+### Added
+
+`check --explain` traces the plan the pending intent makes, after the looks: each planned bump, with the zero-major setting named when it changed the version, and each dependency onto a bumped package, whether it cascades and why, with the range its manifest declares when a range decided it (the reasons for a skip: the range still admits the new version, a development dependency, a dependent that is not version-managed, or one dropped with the package it was first reached through). When the plan cannot be built, it traces nothing and says so. It is text only and cannot be combined with `--json`.
+
+`status --json` and `check --json` list the packages the workspace no longer has, whose tags stay history: each as `{ "name", "ecosystem", "version", "tag" }` for its newest release. `status --json` carries them as `retired`, with `retired_look` saying whether the tags were read (`ran`, or `failed` when they could not be, or a rename stopped the read); `check --json` carries them on the `tags` look, absent when that look could not answer. Text output does not mention them.
+
+A new `oakum workflow` command prints the workflow `init` prints for this repository, alone on stdout, and writes nothing, in a repository oakum already manages too: `mkdir -p .github/workflows && oakum workflow > .github/workflows/oakum.yml` saves it. It takes `--token` and `--app`, and names on stderr what the workflow still needs. A pin naming another version refuses with exit 1, pins that disagree or cannot be read print the workflow and exit 2, and a failed action lookup exits 2 with nothing on stdout. An already-initialized `init` or `migrate` that refuses `--token` or `--app` now names `oakum workflow` with the same flag and secret.
+
+`init` and `migrate` take `--token <SECRET>`, which wires the printed workflow's writing steps and the release checkout to `${{ secrets.<SECRET> || github.token }}`, and `--app`, which prints a GitHub App token minted in each writing job from the `APP_CLIENT_ID` and `APP_PRIVATE_KEY` secrets, with the same fallback and a release job that tags as the App's bot. Under either, the version pull request is skipped by `check --strict` by its branch and repository, since oakum cannot know the account that opens it, so the workflow runs as printed. Each names, as a next step, what the workflow needs that oakum cannot check. The two cannot be combined, and an already-initialized or already-migrated rerun, which prints no workflow, refuses either.
+
+### Changed
+
+`check` now compares the specifiers `pnpm-lock.yaml` records with the workspace's manifests, under a new `lockfiles` look, and exits 1 when they disagree: a dependency range edited, added, removed or moved to another section without running `pnpm install`, a workspace project with dependencies the lockfile has no importer for, or a catalog entry the lockfile records with a value `pnpm-workspace.yaml` no longer gives it. Each finding names the lockfile entry, both values and `pnpm install` as the fix. It compares specifiers only; `pnpm install --frozen-lockfile` still catches settings, `dependenciesMeta`, `publishConfig.directory` and patch changes. This drift used to pass `check` and surface only on the version pull request; the entries `version` leaves and names, such as a registry-resolved one, now fail `check` on that pull request until `pnpm install` runs there. An entry an override the lockfile records was applied to, one its `ignoredOptionalDependencies` patterns leave out, or one a package extension adds is not compared, and a `lockfiles:` line on stderr counts it. A lockfile in a format oakum has not measured (any `lockfileVersion` but `'9.0'`), one recording a pnpmfile, one where `excludeLinksFromLockfile` left out a `file:` or `catalog:` dependency, and an entry or manifest it cannot read exit 2 rather than reading as clean. A repository with no pnpm workspace or no `pnpm-lock.yaml` is unaffected.
+
+`check` now renders the changelog entries the pending bump files would add, as `version` renders them, and exits 1 on any entry `version` would refuse to write: a template whose entry has no heading oakum can read back, one that renders nothing (such as a cascade under a template that writes only when there are notes), and a note that leaves a code fence, HTML comment, `<details>`, `<pre>`, `<script>`, `<style>` or `<textarea>` block open. These used to pass `check --strict` and fail the version job after merge. An entry that fails only because a bump file the base does not hold yet has no commit or pull request, which the merge supplies, is rendered with stand-ins for them and passes, with a note naming it; `version` renders it if the merge's subject carries the pull request. The finding is reported under the `changelogs` look, and both commands now name the bump file whose note left a block open. `check --notes-file <path>` renders the entries with that body in place of the notes, as `version --notes-file` does. With nothing pending, `check` renders nothing.
+
+`init` ends with next steps: `oakum workflow` with the same `--token` or `--app` to save the workflow, through another file so a failed run leaves a saved one in place, `oakum add` for each change (conventional commits under `--change-files false`), `oakum status` to see the plan, and `.changeset/_config.toml` as where `versioning`, `change-files`, and `conventional-commits` are changed. An already-initialized rerun names `oakum workflow` too. `init` and `migrate` no longer print the `--interactive` hint after their writes, when the wizard could set nothing; `oakum init --help` names it.
+
+`migrate`'s look for gates on the old bump-file directory now reads the hooks git runs as well as git's index. A hook naming the old directory (`.bumpy`, matched as the index search matches it) in the hooks directory — `.git/hooks/`, the one `core.hooksPath` names, or the common one from a linked worktree — is named for the reader to repoint, and a hook git would run that oakum cannot read exits 2 (`unverified`) naming it. Only a file named after a git hook event counts, and on Unix only one with an execute bit, as git runs no other. A migration run mid-conflict also exits 2 naming each conflicted file, which `git grep --cached` skips without saying so: such a run used to print "no file in the index … names the old bump-file directory" and exit 0 over a gate in a conflicted file. Hooks defined in git config (`hook.<name>.command`) are still not searched, and the report says so.
+
+When `package.json` gives pnpm its version in a `devEngines.packageManager` array, the workflow `init`, `migrate`, and `oakum workflow` print passes that version to `pnpm/action-setup` as written, a range such as `>=10` or `^11` included, quoted where YAML needs it, trimmed, and without a `+<integrity>` suffix on a single version, instead of asking pnpm for one; under pnpm 11 that question resolved the range and wrote `pnpm-lock.yaml`, a file none of the three owns. An empty or blank version there exits 2, naming the declaration to write, since the action reads it as none, and so does one holding characters outside printable ASCII, which a workflow cannot carry.
+
+The workflow `init` and `migrate` print for an npm workspace runs the repository's own pin: `pnpm install --frozen-lockfile --ignore-scripts`, then `pnpm exec oakum`, in place of `npm i -g @oakoss/oakum@<version>`, so the `@oakoss/oakum` devDependency is the one install pin and no lifecycle script runs during the install. When the root `package.json` lists no `@oakoss/oakum`, both commands name the `pnpm add -D --allow-build=@oakoss/oakum @oakoss/oakum@<version>` that adds it, whatever else pins oakum. Every printed job but `release` checks out with `persist-credentials: false`, and every printed action is pinned by commit SHA with its tag as a comment (`actions/checkout@<sha> # v7.0.1`), the commit its latest release tags, at one more GitHub read per action; a read that fails, a missing tag included, exits 2 and writes nothing. The pull-request comment is split across two jobs, as the GitHub Actions guide's "Posting the comment from another job" describes: `check` runs `ci pr-status --emit-comment` with a read-only token and uploads the comment, and a new `post` job checks out the base commit, installs oakum, and runs `ci post-comment` with the write token, skipping a fork and Dependabot's pull requests, which get no write token; their plan stays in the `check` job's summary.
+
+A changelog heading inside a `<pre>`, `<script>`, `<style>` or `<textarea>` block no longer counts as a version section, matching how CommonMark renders it: `check` no longer reads such a heading as vouching for the version; `check`, `version` and `release` refuse a changelog that leaves one of these blocks open, naming the block and its line, and `version` refuses a bump-file note that does, as they already do for an open HTML comment or `<details>` block. Inside one of these blocks a `#` line is content too: it no longer ends the version's section or the release body read from it, and in a bump-file note it no longer splits the note into Keep a Changelog sections. A `<details>` inside one of these blocks no longer opens a collapsed block, so a heading after the block's closer is a section again. The same holds for a Keep a Changelog heading inside an HTML comment or `<details>` block in a note: the note is written whole, where `version` refused it as leaving the block open. A fence marker inside a comment in a note no longer opens a fence, so a Keep a Changelog heading after the comment now starts its section, where the rest of the note stayed under the level's default section.
+
+A change to a Cargo workspace's root `Cargo.toml` (`[workspace.dependencies]`, inherited `[workspace.package]` fields, profiles and other workspace settings) or to resolved registry and git entries in `Cargo.lock` now counts toward each versioned package whose runtime dependencies it reaches, so `check --strict` refuses it until covered and `generate` releases from it. The report names what moved, as in `tm-cli (cargo): changed (via tm-core, tm-store; Cargo.lock: rusqlite)`, and `--json` carries it as `through`. A change reaching only development dependencies, `[workspace.metadata]`, or the version `version` writes still asks nothing; a root file that does not parse on either side leaves coverage `unverified` (exit 2), as does a member's `Cargo.toml` that is not TOML on the earlier side of a `Cargo.lock` change; a package that was no workspace member there, or whose manifest cargo would have refused there, counts as absent there.
+
 ## 0.9.3 (2026-11-06)
 
 ### Changed
@@ -551,4 +581,4 @@ Release workflow checks out the homebrew tap in a subdirectory so the composite
 
 Self-host release CI uploads cargo-dist artifacts into the GitHub Release oakum already created, instead of calling create again.
 
-Generated by oakum 0.9.2.
+Generated by oakum 0.9.3.

package/npm-shrinkwrap.json

@@ -19,7 +19,7 @@
       "hasInstallScript": true,
       "license": "MIT",
       "name": "@oakoss/oakum",
-      "version": "0.9.3"
+      "version": "0.10.0"
     },
     "node_modules/detect-libc": {
       "engines": {
@@ -48,5 +48,5 @@
     }
   },
   "requires": true,
-  "version": "0.9.3"
+  "version": "0.10.0"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "artifactDownloadUrls": [
-    "https://github.com/oakoss/oakum/releases/download/v0.9.3"
+    "https://github.com/oakoss/oakum/releases/download/v0.10.0"
   ],
   "author": "Jace Babin",
   "bin": {
@@ -105,7 +105,7 @@
       "zipExt": ".tar.xz"
     }
   },
-  "version": "0.9.3",
+  "version": "0.10.0",
   "volta": {
     "node": "18.14.1",
     "npm": "9.5.0"