fix(changelog): regenerate cli 0.8.x entries from git history (proper PR + SHA links)#76
Merged
Merged
Conversation
…kfill script Following the question "why are the new cli entries missing SHA / PR links?" the honest answer was: I wrote them by hand instead of letting `scripts/backfill-changelog.js` do it. The hook auto-runs that script whenever a version bump is staged, but I pre-created the files in the same commits that bumped the version, so the hook saw the files already exist and skipped regeneration. Recovery: delete the four hand-rolled files (0.8.2 .. 0.8.5) and run the backfill script fresh. Script result: ONE new file regenerated: 0.8.5.md, with proper ([#72](pr-link)) and [`<sha>`](commit-link) markup, body extracted from the PR's squash-merge commit message. The intermediate 0.8.2, 0.8.3, 0.8.4 versions were ephemeral states during PR #72 development (we manually `npm publish`ed each one as we iterated), but the squash- merge of #72 onto main collapsed all intermediate bumps into a single 0.8.1 -> 0.8.5 step. From git's perspective on main, those middle versions never existed as separate bumps, so the backfill cannot recreate per-version entries for them. Result is a small "version gap" on the /changelog page: 0.8.5 sits directly above 0.8.1. The intermediate versions are still on npm (install of @webjsdev/cli@0.8.3 still works) but have no rendered release notes; their changes are covered cumulatively in 0.8.5's entry. Going forward, the standard one-bump-per-PR flow produces 1-to-1 mapping between published versions and changelog entries.
This was referenced May 22, 2026
vivek7405
added a commit
that referenced
this pull request
May 22, 2026
…79) The auto-generated entry from PR #76 was technically correct per the script's rules but content-wrong for users. Three issues: 1. Title referenced intermediate names that didn't ship. "create-webjs-app" was renamed to "create-webjs" later in PR #72, and "wjs alias" was dropped (npm's name-similarity filter blocked the unscoped `wjs` package; we settled on `webjsdev` instead). 2. Body misrepresented what cli@0.8.5 specifically contains. The bullet's body was the first 4 lines of PR #72's squash commit body, which happens to describe the cli@0.8.2 auto-install work. 0.8.5 specifically is the `npx webjsdev` banner fix; the rest of 0.8.2- 0.8.4 work (bin map narrowing, output reorder) was invisible. 3. Single bullet under "Features" miscategorised a mix of feat + fix + breaking work. Rewrite as a multi-section entry covering everything the cli has gained since 0.8.1: Features: - auto-install dependencies after `webjs create` - next-steps banner reordered (run command lands last) Fixes: - banner uses `npx webjsdev ui` instead of broken `npx webjs ui` Breaking: - 0.8.2's `wjs` bin alias reverted in 0.8.3 (migration note) See also: - The new `create-webjs` and `webjsdev` companion packages Underlying cause this got auto-generated wrong: PR #72 bundled four cli version bumps (0.8.2, 0.8.3, 0.8.4, 0.8.5) into one squash-merge commit on main. The backfill script walks main's history and sees one squash commit for the 0.8.1 -> 0.8.5 range, so it produces one bullet from the squash subject + first 4 lines of body. Future releases under the "one-bump-per-PR" cadence will auto-generate accurate entries without this hand-edit. Companion to PR #72 title update on GitHub: the PR's title now reads "feat: npx-first scaffold UX (create-webjs + webjsdev + auto-install)" to match the actual deliverables (`create-webjs` not `create-webjs-app`, `webjsdev` not `wjs`). That edit lives on the PR page only; the squash commit's subject in main's git history is unchanged because editing it would require a force-push to main.
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.
Summary
Answering "why no PR / SHA links on the new cli entries?": I wrote those four files by hand instead of letting
scripts/backfill-changelog.jsdo it. The pre-commit hook would have auto-generated them if I'd staged the version bump alone, but I pre-created the files in the same commits, so the hook saw them already exist and skipped regeneration. Fix: delete the hand-rolled ones, run the backfill script fresh.Script result
ONE new file regenerated:
changelog/cli/0.8.5.md, with proper([#72](...))and[](...)markup, body extracted from the PR's squash-merge commit message.The intermediate 0.8.2, 0.8.3, 0.8.4 versions were ephemeral states during PR #72 development (we manually
npm published each one as we iterated). The squash-merge of #72 onto main collapsed all of them into a single0.8.1 → 0.8.5step. From main's git history, those middle versions never existed as separate bumps, so the backfill cannot recreate per-version entries.Visible effect
Small version gap on the website's
/changelogpage:0.8.5sits directly above0.8.1. The intermediate versions are still installable from npm (npm i @webjsdev/cli@0.8.3works), but they have no rendered release notes. Their changes are covered cumulatively in0.8.5's entry.Going forward, the standard one-bump-per-PR flow produces 1-to-1 mapping between published versions and changelog entries.
Workflow safety
The
release.ymlworkflow's "Find new changelog files" step usesgit diff --diff-filter=A, which matches ADDED files only. This PR deletes 3 files (D) and modifies 1 (M); neither matches the filter. So the workflow trigger fires (paths matched) but the publish + lockstep steps see zero new files and no-op cleanly. No risk of spurious re-publishes.Test plan
npm testpasses (1151/1151)/changelogrenders cli entries as0.8.5 → 0.8.1 → 0.8.0 → ...