BuildScopefield notes for faster builds
local measurements

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.

01 / INSTALL

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.

shell
docker pull ghcr.io/buildscope/runner:1.4.0
npm install

The 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.

02 / RUN

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.

shell
npm run benchmark
npm run build
npm run check:public
01
Generate

Write the fixture and collect the timing ledger.

02
Publish

Build the static notes with the latest JSON snapshot.

03
Inspect

Open Artifacts and compare raw, gzip, and Brotli weight.

03 / CONFIGURATION

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.

buildscope.config.json
{
  "target": "es2020",
  "outputDir": "dist",
  "samples": 4,
  "compression": ["gzip", "br"]
}
04 / METHOD

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.

Freshfolder recreated

before every sample

Repeatsame build

after fresh samples

Sizesall files summed

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.