[owjs3901]

Summary

• Every benchmark fixture is a single page, so costs that grow with an app never show up in the numbers: import resolution, barrels, constants read across modules, and work repeated once per module. The audit's perf findings (resolver re-parses, double extraction from the reservation pre-scan, per-module CSS rendering and state export) all fall in that blind spot.
• benchmark/large-app.mjs writes 30 routes that render 300 components through one barrel (@/components). Every component reads shared tokens from another module and uses styled, css, responsive arrays and selectors.
• New rows: devup-ui-large (webpack) and devup-ui-large-turbo (Turbopack), plus -wasm twins that build the same app with engine: 'wasm' to measure the native engine's gain at app scale. They are not gated until a baseline has been calibrated, so this PR can't fail the gate. Generation is included in the timed build, but it writes only files whose content changed (one write per row on a cold CI runner).

Follow-up

Once a few runs have recorded numbers, gate the rows with bun benchmark-check.js --write-baseline. The perf PRs that follow (resolver cache, single extraction, lazy CSS) will be measured against these rows.

Test plan

• Generator output inspected locally (300 components, 30 routes, barrel)
• CI benchmark job builds both rows and prints their timings

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.