fix(extension-chrome): build content scripts as classic IIFE so Chrome injects them

[chrischall]

Root cause

MV3 injects content scripts as classic scripts. A built content-script file that carries a top-level import/export is not a valid classic script, so Chrome silently refuses to inject it — content.ts's chrome.runtime.onMessage listener never registers, and every service-worker→content-script sendMessage fails with "Could not establish connection. Receiving end does not exist" (surfaced by the bridge as "N URL match(es), none responded").

build.ts compiled every entry point with format: 'esm'. That was harmless until 0ce0949 (#148) added export function readDomValues to content.ts: the bundle became a real ES module ending in export { readDomValues };, and content.js stopped injecting. capture-logger.js (no exports) kept injecting — so CSRF/storage capture still worked while every fetch() through the bridge died. That is the "bridge down / Receiving end does not exist" outage seen in the field for the fetchproxy-backed cohort MCPs (opentable, tock); Resy was unaffected because it doesn't use the bridge.

Diagnosed live: on a fresh, signed-in, fully-loaded OpenTable tab, data-fetchproxy-csrf was present (capture-logger alive) yet the fetch still returned "2 URL matches, none responded" — proving the split was content.js-specific, and the built file ended in export { readDomValues };.

Fix

Split the esbuild build:

• background + popup stay esm (genuine modules — manifest "type": "module" and <script type="module">).
• content.ts + capture-logger.ts build as iife, which emits no top-level import/export regardless of what the source exports.

Test

tests/content-scripts-classic.test.ts asserts the content-script bundles contain no top-level import/export (and that content.js still registers its onMessage/fetchproxy-fetch listener). It fails on the old esm config and passes on iife.

Full suite green (985 tests), typecheck clean.

🤖 Generated with Claude Code

[claude]

Claude finished @chrischall's task in 4m 35s —— View job

---

I'll analyze this and get back to you.

[claude]

🟡 Nit: this test's name ("background is loaded as a module service worker") doesn't match what it checks — it only re-asserts the static .format string on the same option objects under test, without ever building/inspecting a background.js bundle. It's tautological (true by construction from the object literals in build.ts) and doesn't add regression coverage beyond what the first describe block already exercises for content scripts. Consider either dropping this test or replacing it with an actual bundle build + assertion that the background output contains a real import/export (mirroring the classic-script checks above, inverted).

Fix this →

[claude]

Review: build content scripts as classic IIFE

Root cause and fix are correct. MV3 content scripts must be classic scripts (no top-level import/export); esbuild's format: 'esm' for content.ts broke injection once readDomValues was exported (#148). Splitting the build into moduleEntryOptions (esm, for background/popup which are genuine modules per the manifest's "type": "module" and <script type="module">) vs. contentScriptEntryOptions (iife, for content/capture-logger) is the right fix, and matches manifest.json's existing classic content_scripts entries.

Other observations, all verified against the code:

• HERE/CORE/OUT now resolve relative to build.ts's own location instead of process.cwd() — a real robustness improvement (previously relied on the script being invoked from the package directory).
• The new process.argv[1]-based guard around void main() correctly prevents the build from running as a side effect when the test imports build.js for its exported option objects — confirmed by the passing CI run (both CI runs for this PR are green, and npm run build + npm test both exercise this).
• tests/content-scripts-classic.test.ts directly encodes the regression (no top-level import/export in the content-script bundles, plus a sanity check that content.js still registers its onMessage listener) — good, targeted coverage of the actual bug.
• I was unable to install dependencies / run the suite myself in this sandbox (npm/node invocations required approval that wasn't available), so I relied on static review plus the CI status API, which shows this PR's CI checks passing.

One nit (left inline): the third test ("background is loaded as a module service worker") doesn't actually build or inspect a background.js bundle — it just re-asserts the static .format field on the same option objects, which is tautological and adds no regression coverage.

No correctness, security, or convention issues found.

Verdict: pass

[github-actions]

🟡 Auto-review verdict: warn — The classic-IIFE build fix correctly resolves the MV3 content-script injection bug and is backed by a targeted regression test; only a minor test-quality nit was found, no correctness/security/convention issues.
📋 Tracking follow-ups: #176