e2e: packaged-app smoke test on macOS and Windows

[juanmaguitar]

Closes #67.

Why

Nothing verifies that the packaged app launches. Packaging failures — asar layout, native module rebuilds, bundled CLI resolution — were only discoverable by downloading an artifact and installing it in a VM.

What

One Playwright _electron test against an unsigned electron-builder --dir build, on macos-latest and windows-latest, for non-draft PRs and pushes to trunk.

1. It boots — the first window appears and the renderer paints.
2. The preload bridge is whole — every contextBridge key is compared against a checked-in list. There is no typecheck in this repo, so nothing else catches an ipcMain.handle added in src/main.js and never exposed in src/preload.js.
3. The bundled runtime modules resolve from inside the packaged app — @wp-playground/cli, and fs-ext on macOS and Linux. fs-ext is an optional native dependency, so a failed rebuild degrades file locking with no error anywhere in the install or build logs; this is the only thing that catches it. Windows is excluded on purpose — the Playground CLI does not load the module there (os.platform() === 'win32' ? undefined : await import('fs-ext'), with an upstream @TODO: Enable fs-ext here when it works with Windows). If that guard ever goes away, Windows belongs back in the list; the note lives next to the module list in the spec.

Deliberately minimal: one spec, no session helper, no page objects, no temp state directories.

Verified

Ran locally on macOS arm64, then broke each thing on purpose to confirm the test can actually go red:

Break	Result
loadFile → a missing file	boot test fails
drop getSites from src/preload.js	bridge test fails, naming the missing key
rm -rf node_modules/fs-ext	resolve test fails
restore everything	all pass

Unit suite unaffected — 28 tests green on both the system Node and Electron's bundled Node; node --test does not pick up e2e/*.spec.js.

Notes

• No application changes, no secrets.
• Rebased onto trunk after Run the unit suite on macOS and Windows, on both Node runtimes #68/Fix the Electron test pass silently breaking on Node 22 and newer #69 landed; the workflow follows the conventions in unit-tests.yml.
• ready_for_review had to be added to the trigger list. It is not in the pull_request default set, so a PR opened as a draft and later marked ready would have skipped its only run and never tested anything. Caught on this PR's own first ready transition.
• CSC_IDENTITY_AUTO_DISCOVERY=false is mandatory on macOS — electron-builder signs during --dir otherwise. Windows signing already no-ops without the Azure env vars.
• electronApp.close() is raced against a timeout and a hard kill, since it hangs on Windows for apps that keep child processes alive.
• No "no uncaught renderer errors on boot" assertion — the page installs its own error handlers and a pageerror listener attaches too late to be reliable.
• Buildkite is untouched and still produces the signed artifacts.

🤖 Generated with Claude Code

[github-actions]

🟡 architecture · [fix here]

@playwright/test pulls in playwright → fsevents (macOS-optional), and the lockfile shows it with hasInstallScript: true (package-lock.json, new node_modules/fsevents entry). It has no corresponding entry in allowScripts below (line 93), unlike the other lifecycle-script deps already listed there (electron, electron-winstaller, esbuild, fs-ext-extra-prebuilt).

Per this repo's convention, a lifecycle-script dependency without an allowScripts entry is a finding regardless of how low-impact this particular one is (dev-only, optional, darwin-only). Add "fsevents@2.3.2": true alongside the existing entries.

[github-actions]

🔵 cross-platform · [fix here]

This fallback signals only the top-level Electron process, not its tree — the same pattern src/kill-tree.js exists specifically to avoid (see its header comment and issue #83: "a plain child.kill() signals only the first link, so quitting the app left watchers and servers running"). The comment two lines up even notes "the app keeps child processes alive."

Right now the three tests in this file never start a real npm-install/server child, so the blast radius is just Electron's own helper processes and it only matters in the already-degraded case where close() hangs. But this fixture is the natural place future e2e tests will exercise startServer/runNpmInstall, at which point a bare proc.kill() here will leak orphaned processes on whichever platform's close() misbehaves. Consider reusing killChildTree (exported from src/kill-tree.js) instead of proc.kill().

[juanmaguitar]

Closing this in favour of #360, which builds the same capability with a wider remit — the plumbing here has to serve journey tests that write real state, not just a smoke test that writes none.

Two things had gone stale enough that this was a rewrite rather than a rebase. The list of bridged keys checks roughly half the entries the app exposes today, and the native module it probes is no longer optional and no longer absent on Windows, so the deliberate Windows exclusion documented in the file now skips the one failure it was written to catch.

What carries over, and it is most of the file:

• The three assertions, unchanged in intent: it boots, the whole bridge is exposed, and the modules that only resolve if packaging worked do resolve. The bridged-key list is the right shape — checked in, edited deliberately, comparing everything rather than a sample.
• Resolving from inside the packaged app anchored at its own entry point, rather than from the test's own module scope, which would answer about the wrong tree.
• Finding the binary across the platform-and-arch output directories.
• Racing close() against a timeout and killing the process after it, because it hangs on Windows in apps that keep children alive.
• Not asserting "no uncaught renderer errors on boot", for the reason written in the file: the page installs its own handlers and the listener attaches too late to be reliable.
• The workflow shape: non-draft pull requests only, both platforms, unsigned --dir, signing discovery disabled, report kept on failure, no browser download step.

#67 stays open. It gets its test back on top of #360, with the key list regenerated and the native module asserted on both platforms.