04 The field guide
Repeat the
good parts.
A compact setup for running the same fixture, keeping the output honest, and making benchmark results useful to the people who inherit them.
Start with the runner
BuildScope keeps the runner intentionally small. Use a checked-out workspace for local work, or use the published image when a clean environment is more useful.
docker pull ghcr.io/buildscope/runner:1.4.0
npm installThe image includes the pinned toolchain. npm install is enough for a local workspace; keep the lockfile beside the fixture so a later run can be reconstructed.
One fixture, two passes
Run a clean pass first, then repeat the same command four times. The first pass captures the cost of an empty output directory; the second pass shows a warm, ordinary edit cycle.
npm run benchmark
npm run build
npm run check:publicWrite the fixture and collect the timing ledger.
Build the static notes with the latest JSON snapshot.
Open Artifacts and compare raw, gzip, and Brotli weight.
Make the run explicit
Keep assumptions close to the fixture. This example records the target, the output directory, and the number of samples without hiding them inside a script.
{
"target": "es2020",
"outputDir": "dist",
"samples": 4,
"compression": ["gzip", "br"]
}Read the evidence
Every published row comes from the local runner’s current machine. The fixture has 36 modules and 292 lines, and every tool receives one entry point and the same output target.
before every sample
after fresh samples
raw + gzip + Brotli
Numbers are rounded to two decimals for timings and one decimal for resident memory. A comparison is only as useful as its fixture, so keep changes visible in the Changelog.