Stop committing the renderer bundle

[juanmaguitar]

Fixes #120.

The esbuild output at src/renderer/index.js and index.css was committed so the app could run without a build step. Regenerating it was a manual step at the end of any renderer change, and forgetting it was silent — the file is not reviewed (2.6 MB of generated output), the linter ignores it, and no job compared it against a fresh build.

It had drifted. Rebuilding on a clean npm ci, with the committed lockfile and the same esbuild (0.23.1), produced 323 insertions / 177 deletions: 33 hunks from index.jsx, 4 from setup-steps.cjs, 1 from update-plan.cjs, and ~60 inside vendored @wordpress/* modules. Most visibly, the isUpdating flag from #111 was absent, so Install / Build / Dev were not gated while a site update ran.

One correction to the issue, which decides the approach

The signed artifacts were never affected. All three Buildkite steps already ran npm run build:once before npm run dist, so shipped builds were made from source and did have the gating. The stale bundle only bit someone running electron . from a checkout.

That left the committed file with no consumer in the shipping path. So this deletes it and makes the build unskippable, rather than adding CI to police a file nobody needs. Drift becomes impossible rather than merely detected — the second of the two directions in the issue.

npm install is already mandatory (main.js needs electron-store, isomorphic-git, …), so hanging the build off the existing entry points costs contributors nothing.

What changed

• The output is gitignored and built by postinstall, start, and every dist script.
• Prefixing start also closes a latent race: concurrently could hand Electron a bundle the first watch build had not written yet. The committed file happened to mask that.
• Buildkite's three separate "Build renderer" steps are gone — the build lives in one place and now covers a local npm run dist too.
• src/renderer/bundle.js / bundle.css removed. Nothing loaded them; leftovers from when the output had a different name.

One deviation from the issue

The issue asks for the bundle lint ignores to go. src/renderer/index.js stays ignored: it is no longer committed, but it still sits next to its own source after any build, so dropping the ignore would lint 55k lines of generated code on a developer machine and nothing on a fresh CI checkout. Only the bundle.* ignores went.

Testing

Verified locally:

• Fresh npm install builds the bundle via postinstall; both files resolve as ignored.
• npm test — 147 pass. eslint . --max-warnings=0 — clean, checked both ways: with the generated bundle present (a developer machine after any build) and without it (CI's npm ci --ignore-scripts skips postinstall, so the bundle never exists there). Keeping src/renderer/index.js in the ignores matters more now that Finish the lint baseline and widen the CI check to the whole repo #119 lints the whole repo at zero tolerance — CI never sees the file, so only a local run would have tripped over it.
• The gating is now in the built bundle: 3 × || isUpdating on Install / Build / Dev, absent from what was committed.
• electron-builder --dir produces an .app whose asar contains src/renderer/index.js and index.css despite the gitignore (electron-builder does not read .gitignore), and the packed bundle has the gating. Launched it — boots and renders.
• Rebuilding leaves git status clean, so the drift class is gone rather than fixed once.

Verified on a signed artifact from Buildkite build #261, all three platforms green. The macOS .dmg was installed and exercised on both paths:

• an existing older site updated to latest trunk successfully, with the app behaving normally throughout
• a new site created from scratch, with every step of the initial setup checklist working as expected

That is the end-to-end check this issue was really about — the shipped renderer now matches its source.

Rebased onto trunk after #119 landed. The only conflict was in .github/workflows/lint.yml, where #119 deleted the changed-files job that held a comment naming the old bundle.js; trunk's version was taken wholesale, so that file is no longer part of this diff. Nothing in the rebase touches the app, so the manual testing above still stands.

Note for reviewers with a local checkout: after pulling, src/renderer/index.js and index.css become untracked-and-ignored. Harmless — npm install regenerates them.

🤖 Generated with Claude Code

[github-actions]

0 findings — 0🔴 0🟡 0🔵. No [fix here] or [follow-up] items across the five dimensions.

This PR stops committing the esbuild renderer output (src/renderer/index.js, index.css) and removes the dead bundle.js/bundle.css leftovers (confirmed unreferenced by index.html or anywhere else). The build now hangs off postinstall, start, and every dist:* script instead of a manual step, closing the drift the commit message documents (the committed bundle was missing the isUpdating gating flag from #111).

Checked against the five dimensions:

• Architecture: no violation of the zero-prerequisites promise — this build step runs at contributor-toolkit development time (npm install/npm start/npm run dist), not inside the packaged app's runtime spawns. Buildkite's install_node_dependencies.sh calls plain npm ci (no --ignore-scripts), so postinstall still runs build:once there; lint.yml's npm ci --ignore-scripts skips it, but index.js stays in the ESLint ignore list regardless of whether it's present.
• Security: no IPC, spawn, or listener changes.
• Performance: build:once now runs twice in the dist scripts (once via postinstall, once explicit) — trivial esbuild cost, not worth a finding per the 'no speculative micro-optimisation' guidance.
• Cross-platform: plain npm scripts, no path or process-spawn changes.
• Tests: this is a build-tooling fix, not an app feature/bugfix reachable from node --test; nothing to reproduce there.

This is a first-pass review (no prior findings to reconcile).

Style / process notes (non-blocking)

None beyond what's already covered above.