Skip to content

Add bundle-size report and CI artifact for every pull request #275

Description

@BorisTyshkevich

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

  1. Enable esbuild metafile: true in the build/report path.
  2. Keep the existing release artifact byte-for-byte equivalent in behavior; reporting must not change production loading semantics.
  3. 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
  4. Add a pull-request workflow step that uploads the report files as a GitHub Actions artifact.
  5. 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

  • npm run size-report succeeds from a clean checkout after npm ci.
  • The report records raw, gzip, and Brotli sizes for dist/sql.html, bundled JS, and minified CSS.
  • The report lists the top 30 contributing modules.
  • External packages, generated code, and hand-written project code are reported separately.
  • Entry-point/chunk totals are included even while the build has only one chunk.
  • Pull-request CI uploads the report and esbuild metafile as an artifact.
  • The report includes base-versus-PR deltas when base measurements are available.
  • Existing tests and the production build remain green.
  • No bundle-size budget fails the build in this initial issue; thresholds are a follow-up based on collected evidence.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions