Problem
The production build emits one self-contained dist/sql.html, but CI does not report what contributes to its size. Raw artifact size alone cannot answer whether growth comes from runtime dependencies, generated schema code, application modules, CSS, or future route chunks.
Without stable measurements, bundle decisions are based on occasional manual comparisons and regressions are discovered late.
Goal
Generate a reproducible bundle-size report on every pull request and upload it as a CI artifact.
The report must include:
- final artifact size: raw, gzip, and Brotli
- JavaScript bundle size: raw, gzip, and Brotli
- minified CSS size: raw, gzip, and Brotli
- top 30 input modules by contributed output bytes
- totals grouped by ownership:
- project source
- generated project code
- external packages, grouped by package
- entry-point and route/chunk totals
- comparison against the PR base branch when available
The current single-file build has one entry point and one output chunk. The report format should still model entry points/chunks so it remains useful if hosted builds later introduce code splitting or route-level lazy loading.
Proposed implementation
- Enable esbuild
metafile: true in the build/report path.
- Keep the existing release artifact byte-for-byte equivalent in behavior; reporting must not change production loading semantics.
- Add a script such as
npm run size-report that:
- performs the production build or consumes its output
- reads the esbuild metafile
- measures raw/gzip/Brotli sizes using deterministic compression settings
- attributes output bytes to inputs and npm packages
- emits both machine-readable JSON and a human-readable Markdown or HTML report
- Add a pull-request workflow step that uploads the report files as a GitHub Actions artifact.
- When a base-branch report can be produced, include absolute and percentage deltas. Do not fail initially on growth; establish a baseline before adding budgets.
Suggested output files
bundle-size-report.json
bundle-size-report.md or bundle-size-report.html
esbuild-meta.json
Attribution rules
src/generated/** is reported separately from hand-written src/**.
node_modules/<scope>/<package>/** is grouped under <scope>/<package>.
- other
node_modules/<package>/** paths are grouped under <package>.
- build template, third-party notices, and CSS are listed explicitly rather than hidden inside an unexplained HTML remainder.
- percentages use the relevant output total and do not sum compressed per-module estimates unless the report clearly labels them as estimates; compression is not additive.
Acceptance criteria
Follow-up after baseline
After several pull requests establish normal variance, add explicit budgets for total compressed transfer size, initial route size, and unusually large per-package growth.
Problem
The production build emits one self-contained
dist/sql.html, but CI does not report what contributes to its size. Raw artifact size alone cannot answer whether growth comes from runtime dependencies, generated schema code, application modules, CSS, or future route chunks.Without stable measurements, bundle decisions are based on occasional manual comparisons and regressions are discovered late.
Goal
Generate a reproducible bundle-size report on every pull request and upload it as a CI artifact.
The report must include:
The current single-file build has one entry point and one output chunk. The report format should still model entry points/chunks so it remains useful if hosted builds later introduce code splitting or route-level lazy loading.
Proposed implementation
metafile: truein the build/report path.npm run size-reportthat:Suggested output files
bundle-size-report.jsonbundle-size-report.mdorbundle-size-report.htmlesbuild-meta.jsonAttribution rules
src/generated/**is reported separately from hand-writtensrc/**.node_modules/<scope>/<package>/**is grouped under<scope>/<package>.node_modules/<package>/**paths are grouped under<package>.Acceptance criteria
npm run size-reportsucceeds from a clean checkout afternpm ci.dist/sql.html, bundled JS, and minified CSS.Follow-up after baseline
After several pull requests establish normal variance, add explicit budgets for total compressed transfer size, initial route size, and unusually large per-package growth.