Repository navigation
chore: back-merge v0.12.4 into next (real merge) - #151
Merged
Merged
Conversation
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…ks cross-repo (#118) `resolve-env.yml` does `actions/checkout` (which checks out the **caller's** repo) and then `uses: ./actions/branch-env-map`, a path that only exists in voidflow's own repo. Every cross-repo caller therefore fails at that step with the action not found. Found rolling resolve-env into taraxvoid.net (`resolve-env / Resolve env: Run ./actions/branch-env-map` failed on the PR run). Fix: inline the mapping in the workflow (no checkout, no local action). A reusable workflow has no way to reference its own repo's composite action at a matching ref, so the script is duplicated; `test/branch-env-map.test.ts` asserts the two scripts are byte-identical and runs the mapping for every ref/event case in both modes (default `main/next/live` to `dev/staging/prod`, and `single-environment`), against both copies. Also asserts the workflow has no `uses` steps, so this cannot regress. Validating on a real runner via taraxvoid.net#20 pointed at this branch; result to follow here. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
docs: fix stray conflict marker and lefthook remote ref comment
#122) The README told sites to wire `check:licenses` and `test:e2e:lighthouse` through `bunx --package @taraxvoid/voidflow@<version> …`. `bunx` reads the **global** `~/.bunfig.toml`, so a global `minimumReleaseAge` that doesn't exclude voidflow blocks it locally (pre-commit hook included) for 3 days after each release, and the pinned version lives outside the lockfile and Renovate. Sites already have voidflow as a devDependency, so the bins are in `node_modules/.bin`. queeromaha and soundry already call them directly; synthomaha is switching in taraxvoid/synthomaha#100. This updates the README to match and drops the stale 0.8.1 pin. Not verified: why synthomaha CI run 37051879514 failed with `No version matching "0.11.1"` — I couldn't reproduce it now that 0.11.1 is past the age gate. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
… hooks (#119) The shared site hooks hardcoded `bun run --if-present`, which blocks the pnpm sites (rvnflt, voidsite) from adopting them. A top-level lefthook `templates:` entry `pm` resolves to `pnpm` when the repo has a `pnpm-lock.yaml`, else `bun`, and every command uses `{pm} run --if-present`. The install hints use `{pm} install` too. Also fixes the header comment (`ref` is a tag or branch, not a SHA). Tested as a `file://` remote in throwaway repos: the bun repo runs `bun run` for each step, the pnpm repo (with a stub `pnpm` on PATH) runs `pnpm run --if-present` for each step. `lefthook validate` passes and the unit test now asserts the lockfile detection and that no `bun run` remains. Note: `bun run --if-present audit` falls through to macOS's `/usr/sbin/audit` when a site defines no `audit` script. Pre-existing and harmless for sites that define one. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
…--components--voidflow chore(main): release 0.12.0
…rity updates (#124) Security PRs now come from GitHub Dependabot security updates (repo setting, no config file; enabled on both accounts). Renovate's `vulnerabilityAlerts` reads the same GitHub alerts, so leaving it on would open duplicate PRs. Version updates are unchanged. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> <!-- Base branch: feature PRs target `next`. Only hotfixes go straight to `main` (they are back-merged into `next` automatically). See RELEASING.md. --> ## What and why Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
🤖 I have created a release *beep* *boop* --- ## [0.12.1](v0.12.0...v0.12.1) (2026-10-06) ### Bug Fixes * **renovate:** drop Renovate security PRs in favor of Dependabot security updates ([#124](#124)) ([63a1b6f](63a1b6f)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: ravenflight-releases[bot] <330165707+ravenflight-releases[bot]@users.noreply.github.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
#132) The README told sites to wire check:licenses and test:e2e:lighthouse through bunx --package @taraxvoid/voidflow@<version>. bunx reads the global ~/.bunfig.toml, so a global minimumReleaseAge that does not exclude voidflow blocks it locally for 3 days after every release, and the pinned version lives outside the lockfile and Renovate. Sites already depend on voidflow as a devDependency, so the bins are in node_modules/.bin. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
…rity updates (#133) Security PRs now come from GitHub Dependabot security updates (a repo setting, no config file). Renovate's vulnerabilityAlerts reads the same GitHub alerts, so leaving it on would open duplicate PRs. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
- **feat(ci): skip the bunfig security scanner in CI by default** - **fix(bun-install): verify the scanner-free bunfig by parsing it, not grep** --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Settle on license-checker-rseidelsohn 5.x (final stable) instead of the 0.x @lizenz/checker. Its bin is `license-checker-rseidelsohn`, not `license-checker`, so check-licenses now invokes that name. BREAKING CHANGE: sites must replace their `@lizenz/checker` (or `license-checker`) devDependency with `license-checker-rseidelsohn`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
🤖 I have created a release *beep* *boop* --- ## [0.12.2](v0.12.1...v0.12.2) (2026-10-12) ### Bug Fixes * **renovate:** drop Renovate security PRs in favor of Dependabot security updates ([#133](#133)) ([183877f](183877f)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: ravenflight-releases[bot] <330165707+ravenflight-releases[bot]@users.noreply.github.com>
check-licenses ran `bunx license-checker-rseidelsohn`, so the checker version was decided by each site, or fetched as the unpinned `latest` when the site lacked the devDependency. - Add `license-checker-rseidelsohn` `5.0.1` (final stable; `6.0.0-rc.1` is prerelease) as an exact-pinned dependency. - Resolve its bin from voidflow's install and run it with `process.execPath` instead of `bunx`. - Test guarding the exact pin and the absence of `bunx`. - README: sites no longer need their own devDependency. Note: 5.0.1's `--version` prints `4.4.2` (hardcoded upstream); the installed package is 5.0.1. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
🤖 I have created a release *beep* *boop* --- ## [0.12.3](v0.12.2...v0.12.3) (2026-10-12) ### Bug Fixes * pin license-checker-rseidelsohn as a voidflow dependency ([#138](#138)) ([a0d8dd1](a0d8dd1)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: ravenflight-releases[bot] <330165707+ravenflight-releases[bot]@users.noreply.github.com>
…ckout (#141) Why 0.12.2 never reached npm: 1. Run 38204136468 (push of #130, f84a0f6) was in flight when release PR #137 merged (56239c2). 2. release-please reads the branch through the API, so that run created v0.12.2 on 56239c2 and set `release_created=true`. 3. The publish job checked `git merge-base --is-ancestor v0.12.2 HEAD`, but HEAD was the run's own checkout (f84a0f6), so it failed with "Tag v0.12.2 is not on branch main". 4. #137's own run (38204156854) found v0.12.2 already released, so `release_created` was false and publish was skipped. Fix: compare the tag against `refs/remotes/origin/<branch>`, which the job's `fetch-depth: 0` checkout fetches after release-please has finished. This keeps the same guarantee (the tag is on this channel's branch) and works no matter which push's run creates the release. 0.12.3 replaced 0.12.2 on npm, so I'm not republishing 0.12.2. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Two consumer-facing items reported from trailguide: - **`@playwright/test` peer marked optional** (`peerDependenciesMeta`). Only the `./playwright` export imports it. As a required peer, bun auto-installed it in every consumer, including repos that only use the bins. I checked by packing this branch and installing the tarball into an empty project: no `@playwright/*` in `node_modules`, and the installed `check-licenses` bin runs and passes there. - **README: don't set `parallel: true` under `pre-commit:`.** A site's hook-level `parallel: true` applies to the merged hook, so the shared steps all start at once and their `priority` order is ignored (in trailguide, SQLite-backed tests timed out). `lefthook/site.yml`'s comment is left alone because next changed those same lines, and editing them here would cause another back-merge conflict. Squash-merging folds both into one changelog entry under the PR title; a merge commit keeps them as two. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
🤖 I have created a release *beep* *boop* --- ## [0.12.4](v0.12.3...v0.12.4) (2026-10-12) ### Bug Fixes * make the @playwright/test peer optional ([#142](#142)) ([a40fe21](a40fe21)) * **release:** check the tag against the branch tip, not the run's checkout ([#141](#141)) ([9dad79b](9dad79b)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: ravenflight-releases[bot] <330165707+ravenflight-releases[bot]@users.noreply.github.com>
The `back-merge` job opens the main to next PR but left the merge method to whoever merged it. The `next` ruleset allows squash (feature PRs need it for release-please), so back-merges #123, #128, #140 and #145 were all squashed. A squash leaves main's commits out of next's history, so each following back-merge re-conflicts on the same lines (this just happened merging v0.12.4 into next). - `release-please.yml`: after creating (or finding) the back-merge PR, run `gh pr merge --auto --merge`, so it lands as a merge commit once required checks pass. - `RELEASING.md`: document the auto-merge and why a manual merge must never be a squash. `just promote` is unchanged: auto-merging a promotion would skip the review before a stable release. actionlint passes; `bun test` 116 pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
#145 and #148 were squash-merged, so main's commits never became ancestors of next and the promotion PR (#143) kept conflicting. This is a true merge of origin/main into next. It also removes the duplicate `templates:` block in lefthook/site.yml and the duplicate `parallel: true` README paragraph that #148's squash introduced. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Merge with "Create a merge commit". Do not squash. Squashing this repeats the bug it fixes.
#145 and #148 were both squash-merged, so main's commits never became ancestors of
next. That's why the promotion PR #143 still shows conflicts: its merge base is from before 0.12.x. This PR is a true two-parent merge oforigin/mainintonext.Conflicts (version files,
lefthook/site.ymltypecheck step, its test) keep next's side, the same as earlier resolutions. It also fixes damage from #148's squash, which leftnextwith:templates:block inlefthook/site.ymlparallel: trueparagraph inREADME.mdAfter this, the tree differs from
mainonly by #135 (check:precommit) and the0.13.0-next.1version. It also brings #149 (back-merge PRs auto-merge with a merge commit) intonext.bun test: 117 pass.🤖 Generated with Claude Code