chore: release core 0.7.45, vscode 0.2.3, nvim 0.2.3

[vivek7405]

Releases three packages. @webjsdev/core 0.7.45 ships the #1114 fix to the browser bundle: until this publishes, webjs.dev and every app on latest keep serving the buggy prefetch path.

Audit: what is owed, and what is not

Checked every published package against its own latest changelog/<pkg>/<version>.md, not just the one the last PR touched.

Package	Commits since ITS last release	Owed
core	f34fa5c9	yes, patch
vscode	e07ea3a1, 28e5be9a, f41d105b	yes, patch
nvim	f41d105b, plus the re-vendor in this PR	yes, patch
server	none	no
cli	none	no
mcp	none	no
intellisense	none	no
ui	2 commits, both touching only packages/ui/packages/website	no

Three rows are worth explaining, because each is a way an audit goes wrong.

ui is not owed, despite git log -- packages/ui/ showing two commits. Both are confined to the nested website sub-app, which is not published. The published surface (src, bin, registry, README) is untouched, so bumping it would ship a version whose changelog describes changes users never receive.

The editor plugins ARE owed, and my first pass said they were not. I dismissed them with "intellisense is unchanged, so neither plugin owes a republish". That is the wrong test: the question is whether each plugin's own shipped bundle changed since THAT PLUGIN's last release. It had. packages/editors/vscode/src/extension.js still opened https://docs.webjs.dev in its "open documentation" command after the docs moved onto the main domain (#1101), and packages/editors/vscode/README.md (packaged into the vsix, rendered as the Marketplace listing page) carried a brand-casing fix. Both are user-visible in a published artifact.

The nvim re-vendor is the reason that plugin has a release at all. Its vendored @webjsdev/intellisense copy had current src/ but a package.json still declaring 0.5.1 against a real 0.5.4, so the published plugin misreported which language-service version it ships. Worth noting the drift guard structurally cannot catch this: vendor-sync.test.mjs byte-compares only src/, while the vendor script also copies package.json.

What merging actually does

• core: release.yml publishes 0.7.45 to npm and GitHub Packages with a freshly built dist/ (gitignored in-repo, built by prepare), and cuts a core@0.7.45 GitHub Release.
• vscode and nvim: nothing automated. Both changelogs carry npm: false, and all three publish scripts (publish-npm.js, publish-github-packages.js, publish-release.js) skip on that flag, so there is no npm publish, no GitHub Release and no tag for either. Their only automated output is the /changelog entry.

Mechanics

• All three are patch bumps. Every core dependent pins ^0.7.0 or ^0.7.1, so 0.7.45 satisfies them all and no dependent package.json needs editing. Nothing pins either plugin.
• package-lock.json regenerated after all three bumps; npm ci verified consistent.

The core changelog entry is hand-written, deliberately

The pre-commit hook generated it automatically and the output was unusable, for two reasons worth recording:

1. Truncated. The entry cut off mid-sentence.
2. Factually wrong. A squash of a multi-commit PR concatenates the individual commit messages, so the generated body led with my FIRST commit's explanation, which review later disproved (it claimed a self-prefetch returns a "near-empty fragment", when it returns a normal fragment anchored at the innermost layout). Shipping that would have propagated a retracted diagnosis into the public changelog and the Release notes.

Rewritten to the house style and the final understanding, split into the two user-facing changes: the fix, and the new webjs:navigation-fallback event, which is public API worth its own line.

Process note: this is a general hazard. Any squash of a multi-commit PR whose early commits were later corrected feeds a stale narrative to the generator. Setting the squash body explicitly at merge time would avoid it.

Verification

• Changelog frontmatter matches sibling files exactly (field names, order, quoting, ISO date) in all three.
• /changelog renders all three versions, their entries, and their change counts.
• webjs.nvim vendored-intellisense drift guard passes, and the vendored package.json now matches the real one byte for byte.
• backfill-changelog.js is existsSync-guarded, so a later commit on this branch regenerates nothing and cannot conflict.
• Invariant 11 clean across all three changelog files and this body.

After merge (not automated)

• webjs.nvim: subtree split + force-push to the webjsdev/webjs.nvim mirror, then a v0.2.3 release there. I can do this.
• VS Code extension: vsce publish to the Marketplace and Open VSX needs credentials I do not have, so that one is yours.

[vivek7405]

Two findings on my own release audit, both real, both fixed in d854d79a.

I used the wrong test for the editor plugins. I wrote "since intellisense is unchanged, neither editor plugin owes a republish". The question is not whether intellisense changed since ITS last release, it is whether each plugin's own shipped bundle changed since THAT PLUGIN's last release. Checking changelog/{nvim,vscode}/0.2.2.md (both added by 31ac51ba on 2026-06-24) against main turns up three commits touching the plugin trees.

The VS Code one is not cosmetic: packages/editors/vscode/src/extension.js still opened https://docs.webjs.dev in its "open documentation" command, and the docs moved onto the main domain in #1101. That is user-visible behaviour in a published artifact, and it is precisely the stale-host class that @webjsdev/core 0.7.44 was released on its own to fix. Shipping a core release while leaving that sitting would have been the exact release-debt-accumulates failure the audit exists to prevent. webjs.nvim separately carries a refreshed committed intellisense bundle. Both now bumped to 0.2.3 with changelogs, npm: false retained.

The changelog mischaracterised willReload, in the entry whose whole justification was replacing a factually stale auto-generated one, which makes it worth calling out rather than quietly fixing. I wrote that it distinguishes "a click that became a document load from a background operation that was merely dropped". That binary is wrong: deploy-mismatch-reload-suppressed fires with willReload: false on a FOREGROUND click (the enclosing branch is gated on !revalidating), where the page proceeds in place on a stale importmap. A listener written against my sentence would have classified that as a background drop. Reworded to describe what the flag actually means: true only when a document load follows, with both in-place cases named.

The rest of the audit held up: patch level is right, ui genuinely is not owed (both its commits touch only the non-published nested website), server / cli / mcp / intellisense have nothing since their last releases, dependent ranges all still resolve, and the lockfile is consistent.

[vivek7405]

Second pass, on the two plugin bumps that round 1 added and that had therefore had no review at all. Five problems, all fixed in da431bfb (branch squashed, because two of them were wrong statements baked into a commit message).

The lockfile was stale for the plugins. I regenerated it for the core-only commit and never re-ran it after adding the plugin bumps, so it still recorded both at 0.2.2. No CI check catches this, so it would have landed as drift on the next contributor's install. The previous plugin release updated exactly these two lines, which is the precedent I should have followed.

The VS Code entry undercounted and, worse, omitted its most user-visible change. Three commits touch that package since 0.2.2, not two. The missing one is 28e5be9a, which edited packages/editors/vscode/README.md. That file is not in .vscodeignore, so it is packaged into the vsix and rendered as the Marketplace listing page. I had attributed a JSDoc line nobody sees while leaving out the text every prospective user reads. commit_count is also public (the changelog page renders it as "N changes"), so it was wrong on the site too.

I had the release mechanism backwards, in the PR body and in the commit message. I wrote that npm: false means "publish-npm skips the registry and release.yml only cuts GitHub Releases". publish-release.js skips on the same flag, with an explicit comment that the derived tag would be garbage for a display-name package. So merging cuts no Release and no tag for either plugin; the only automated output is the changelog entry. Stated correctly now, and the commit message was rewritten rather than left to carry the error into permanent history.

The nvim vendored bundle was not current, on an axis the drift guard cannot see. vendor-sync.test.mjs byte-compares only src/, while the vendor script also copies package.json. The vendored copy declared 0.5.1 against a real 0.5.4, so the published plugin misreported which language-service version it ships. Re-vendored. This also turns the nvim bump from "a JSDoc pass" into a release with an actual reason to exist. My "the drift guard passes, so the bundle is current" line was an over-claim on precisely the uncovered axis, which is the kind of sentence worth not writing.

Both plugin entries filed comment-only changes under ## Fixes with wording implying user-visible behaviour. The 0.2.2 siblings handled the identical situation honestly, labelling it "Republish:" under Features and saying plainly that there was no source change. Both entries now say what actually changed and name the no-behaviour-change commits as such.

Nothing else moved: core's bump level, the ui exclusion, dependent ranges, frontmatter shape, tag-collision safety, and the subtree flow all still check out.

[vivek7405]

Third pass, checking whether round 2's corrections introduced problems of their own. The source tree came back clean (vendor tree is exactly one changed file and now byte-identical to the real package.json, every SHA correctly attributed, squash contents complete with no strays, lockfile consistent under npm ci, backfill idempotent, and the publish pipeline confirmed end to end). Four problems, all in the prose, all fixed in da431bfb.

I fixed the release-mechanism error in the commit message and left it standing in the PR body. The body still said npm: false means "release.yml only cuts GitHub Releases for them", which is the exact claim round 2 retracted. Both are read by different audiences and I only corrected one. Now stated properly: all three publish scripts skip on that flag, so the plugins get no npm publish, no GitHub Release and no tag, and their only automated output is the changelog entry.

The audit table contradicted the changelogs it exists to justify. Round 2 added the missing README commit to changelog/vscode/0.2.3.md (raising commit_count to 3) but I never updated the table, which still listed two commits for vscode and one for nvim. The table is supposed to BE the audit of record, so leaving it at pre-fix numbers is worse than not having it.

Both plugin changelogs had #855 link text pointing at a commit URL. A reader clicking a PR reference would land on a commit page, and it was inconsistent with the correct two-link form used elsewhere in the same files. Both now use ([#855](.../pull/855)) [f41d105](.../commit/f41d105b).

The nvim entry was filed under Features while its own body described a fix. It headlines "the bundle is refreshed" but the substance is that the vendored package.json misreported its version, which is a metadata correction. Moved to Fixes and retitled to say what was actually wrong. This is the same categorisation error round 2 caught on the vscode side, just in the other direction, which is a fair sign I was pattern-matching the sibling file rather than reading what the change did.

Nothing else moved.

[vivek7405]

Clean. Fifth pass, verifying round 4's fix and hunting for anything the previous four missed.

The PUBLISHING.md correction checks out against the actual mechanism: the pre-commit hook does require a changelog/vscode/<version>.md for a staged bump (only the lockstep wrappers are exempt), backfill's PACKAGES list includes both editor packages, its NON_NPM set is what emits npm: false, and all three publish scripts plus release.yml honour that flag. So "the bump requires a changelog, and nothing publishes automatically" is now an accurate description rather than the inverse of one. packages/editors/nvim/PUBLISHING.md makes no equivalent claim, so there was no second instance to fix.

File set is exactly the nine expected: three changelogs, three version bumps, the vendored intellisense manifest, the lockfile, and that one doc. The vendored manifest is now byte-identical to the real package. Every bumped package has a matching changelog, every core dependent still resolves.

Ran the tests that actually touch this surface (changelog-editor-packages, vendor-sync, published-package-dirs, release-branch-guard, the vscode extension test): 19 of 19. No release-ordering hazard from shipping three packages in one merge, since only core reaches a publish script.

Worth noting what this loop cost, because it is the argument for running it on release PRs at all: five rounds, and the first four each found something that would have shipped. Two were wrong statements about what merging does, one was a stale lockfile, one omitted the only user-visible change in the VS Code release, and one was a release procedure telling the next person to skip a required step. None of them are code, and CI would have caught none of them.