diff --git a/.gitignore b/.gitignore index 8b2407367295..7d76b708a0d9 100644 --- a/.gitignore +++ b/.gitignore @@ -39,6 +39,7 @@ legacy.d.ts # Bundle analysis artifacts bundleAnalysis bundleAnalyzerJson +compareBundlesOutput # Misc pipeline artifacts artifacts diff --git a/build-tools/packages/build-cli/docs/bundleAnalysisRepoDetails.md b/build-tools/packages/build-cli/docs/bundleAnalysisRepoDetails.md new file mode 100644 index 000000000000..d72956dacf5d --- /dev/null +++ b/build-tools/packages/build-cli/docs/bundleAnalysisRepoDetails.md @@ -0,0 +1,164 @@ +# Further information about the bundle-analysis commands + +The bundle-analysis commands measure how a change affects a package's webpack +bundle by building the bundle on two different revisions and diffing the +per-asset and per-package sizes, so regressions (or wins) are easy to spot +before pushing. + +See [generate.md](./generate.md) and [check.md](./check.md) for the generated +command reference. This document explains how the commands fit together and how +to read the comparison report. + +## The commands + +| Command | Responsibility | +| ------------------------------------------------- | ---------------------------------------------------------------- | +| `flub generate bundleAnalysisRepo` | Build one bundle and save its stats under a label. | +| `flub check bundleAnalysisReposComparison` | Diff two already-collected bundles and write the report. | +| `flub generate bundleAnalysisReposWithComparison` | Orchestrate both collect steps plus the compare step end-to-end. | + +Each collected bundle is identified by a **label** — the name of the subdirectory +under `compareBundlesOutput/analysis/` where that bundle's `analyzer.json` is written. +`flub generate bundleAnalysisRepo` assigns the label automatically: the sanitized +revision it built in revision mode, or a timestamped `current_` for the +local working tree. `flub check bundleAnalysisReposComparison` then selects which +two saved bundles to diff by their labels (`--base-label` and `--current-label`). + +Each command self-describes its flags via `--help`: + +```sh +flub generate bundleAnalysisRepo --help +flub check bundleAnalysisReposComparison --help +flub generate bundleAnalysisReposWithComparison --help +``` + +## Typical workflow + +In almost every case you just want the one-shot orchestrator: + +```sh +flub generate bundleAnalysisReposWithComparison +``` + +This compares your working tree against the merge-base of `HEAD` and `main` — +i.e. the point your branch forked from — so the diff reflects only your own +changes, not unrelated commits that have since landed on `main`. Use +`--base-revision` to compare against a different branch, tag, or commit; the +merge-base of that revision and `HEAD` is what actually gets built. + +Reach for the lower-level commands when the orchestrator's flow doesn't fit: + +- **`flub check bundleAnalysisReposComparison` on its own** — when both bundles are + already collected and you only want to re-run the diff (e.g. tweaking the + report, or comparing two labels the orchestrator wouldn't pair automatically). + It reads each side's previously saved `analyzer.json` and writes a fresh report + without rebuilding anything. +- **`flub generate bundleAnalysisRepo` on its own** — when you want to capture a + single bundle without immediately diffing it, or to pre-populate a label for a + later comparison. + +## How collection works + +`flub generate bundleAnalysisRepo` runs in one of two modes: + +- **local** — builds the bundle from the outer enlistment (your working tree, + including staged changes). The staged diff is captured alongside the report so + the measurement is reproducible. The outer repo's git state (working tree, + branch, revision) is never modified. +- **revision** — builds the bundle from a _separate_ inner clone of the repo + checked out at a specific commit. The inner clone is created on first use by + cloning directly from the outer enlistment on disk — no remote or network + access is involved, and every object the outer repo already has (including + merge-base commits that aren't branch tips) is available without a fetch. The + requested commit must therefore already exist locally in the outer repo. The + outer repo's working tree, branch, and stash are never touched. + +Each build runs webpack, which emits `bundleAnalyzerJson/analyzer.json` +(webpack-bundle-analyzer's JSON report). That single file carries per-asset +parsed/gzip sizes and per-module breakdowns — everything the comparison needs — +so it is the only artifact saved per label; the larger webpack stats and `build/` +outputs are not retained. + +The orchestrator runs `flub generate bundleAnalysisRepo` once in each mode: local +for the current side, revision for the base side. The base-side report is cached +and keyed by the resolved SHA, so a re-run against the same merge-base skips the +rebuild. + +## Outputs + +- Each label's `analyzer.json` is saved under `compareBundlesOutput/analysis/