Prove a bundled guard still blocks, and settle sideEffects with a measurement

[patchstackdave]

Two questions about how this package behaves once a consumer builds it, and the answer to a third that had not been asked.

Bundled consumers

Most consumers of the runtime guard are bundled — a Worker through wrangler, a Next edge middleware, a SvelteKit adapter build — and all of them tree-shake. A guard that has lost the part which screens requests still starts, still logs and still looks installed, and the failure arrives in the consumer's build rather than here.

npm run test:bundled bundles a real edge guard with esbuild through the workerd export condition, minifies it, and puts the published CVE-2017-5941 exploit through the bundled output in a separate process: exploit blocked with 403, benign control allowed, route scope honoured. Per-shape size ceilings catch the other regression that matters — a top-level side effect or a heavy static import added to the root entry, which would put the scanner into every consumer's bundle.

edge guard (workerd condition, runs the canary)
  ok    as published            97.3 kB   exploit=403 benign=allowed other-route=allowed
  ok    sideEffects: false      97.3 kB   exploit=403 benign=allowed other-route=allowed
  ok    no `module` field       97.3 kB   exploit=403 benign=allowed other-route=allowed

one symbol from the root entry
  ok    as published             0.8 kB

sideEffects: false is not declared

It changes both consumer shapes by zero bytes; the root entry already shakes to 0.8 kB for a single-symbol import. The field would buy nothing while standing as a permanent promise to every bundler that no module here ever needs evaluating — and the day someone adds a top-level registration, consumers lose it silently in their own build.

npm run audit:side-effects supports that decision without settling it. It is a report, not a check: it names what every emitted artifact executes at import time and exits zero on what it finds. There is no honest threshold to fail on — a CommonJS bundle executes at module scope by construction, dist/cli.js ends in main().then(…) because a bin is supposed to run, and a benign lazy-init call in a library entry is indistinguishable from a harmful one given only syntax. What it cannot see is what a called function does.

Two things keep it from being decorative. --selftest is the gating half and CI runs it first: 31 cases across three outcomes, because an import with bindings is neither a finding nor safe — it evaluates another module, and that evaluation is exactly what is invisible. And discovery is recursive over dist/, covering all 14 emitted .js/.cjs files including the scaffolder's guard templates under dist/protect/templates/, which are the files copied into a consumer's application and executed there. Zero artifacts is an error rather than a clean report, since a summary saying nothing executes anywhere reads exactly like a pass. tests/side-effect-audit-discovery.test.ts drives all of that against temporary directories and checks the real report against an independent walk of dist/.

Local constants are resolved so new Set(PHASES) over a frozen array declared above it is not reported, while unresolved names stay foreign.

module is kept

Removing it also changes nothing, but only because esbuild resolves through exports — which is what exports is for. Webpack 4 and older rollup setups predate it and fall back to module. The measurement cannot see those, so a zero delta is not evidence that dropping it is safe, and the script prints that caveat rather than letting the number speak for itself.

Source maps: published, without the source text

975 kB → 434 kB packed; 3.55 MB → 1.77 MB unpacked. Maps were 68% of the package.

A map without sourcesContent still resolves a stack frame to the original file and line, which is what a support conversation needs. The source text it embedded is public in this repository at the tag matching the version the CLI reports.

Two build steps produce maps independently — tsup.config.ts for three artifacts and scripts/build-edge.mjs for the edge bundle — so tests/source-maps.test.ts asserts over the artifacts rather than the configuration: every emitted JavaScript file has a map, every file points at its map, every map has real mappings and sources, no map embeds source text, and a real thrown frame resolves to the statement that threw. That last one runs resolveConfig with a malformed site UUID under --enable-source-maps and reads the resolved line back out of src/config.ts, so a map whose mappings are present but wrong fails it.

One required status

Requiring the jobs directly means branch protection names matrix labels — Consumers on npm 11.6.0, Validate on Node 24.x — which change with every version bump, and a required context whose name no longer exists is never satisfied rather than reported missing.

Required CI gate depends on the capability contract, the whole consumer matrix, the bundled consumer, the Windows smoke test, the whole Node matrix and the production audit. It uses if: always(), because a skipped required check reads as success to branch protection and the gate would then pass precisely when something was broken. It refuses to pass while standing on fewer jobs than it is meant to require.

After merging, branch protection needs updating: replace Production dependency audit and the three Validate on Node … contexts with Required CI gate.

1721 tests, typecheck, build, the audit self-test, the bundled proof and all 7 consumer shapes pass.

[coderbuds]

Comprehensive CI enhancements with targeted tests for bundling and side-effect auditing.

🎯 Quality: 90% Elite · 📦 Size: Large — consider splitting if possible

📈 This month: Your 150th PR — above team average · Averaging Excellent

_{See how your team is trending →}

[patchstackdave]

/review