| name | bundle-size-bake-off |
| description | Run a "bake-off" to reduce the bundle size impact of changes using subagents |
| metadata | {"author":"François Best <francoisbest.com>"} |
Spin up a number of subagents (as told by the user or 4 by default) to find an implementation
that yields a smaller bundle size for the current PR, branch or changes we're working on.
Tools
To measure the bundle size: pnpm build --filter nuqs && pnpm run --filter nuqs test:size
- Always build first using the root command to leverage Turbo caching
pnpm run --filter nuqs test:size will print the size on stdout. pnpm run --filter nuqs build:size-json will write it to a packages/nuqs/size.json file. Both will fail if the size is over the limit.
Process
The main metric we want to reduce is the Client bundle size (minified & brotli-compressed).
size-limit does all the processing and gives out a metric, no other build steps are needed: this is a trial and error process.
You (the main agent) are not to do this work yourself: delegate it to N subagents. Each subagent works in its own worktree. (you create them and set them up with pnpm setup:worktree at the baseline SHA1), with the following instructions:
- Start by measuring the baseline bundle size before making changes
- Reason about and refactor scoped pieces of code (renaming things, organising logic, merging & splitting functions)
- Measure the bundle size again
- If the changes are over the baseline, revert them and start over.
Otherwise, commit it as a checkpoint, and keep going for a few rounds based on the changes complexity.
- Once you have a good candidate, squash the checkpoint commits into one "chore: reduce bundle size" commit.