Testing and CI
Recommended test layers, CI commands, and production release checks for registry-build consumers.
Treat generated registry output as production code. The build should be tested at the config layer, the phase layer, and the packed CLI layer.
Recommended test layers
| Layer | What to test | Why |
|---|---|---|
| Config tests | loading, defaults, merge, extends, validation | catches wrong config shape early |
| Extension tests | index-build, components, colors, component-index, adapters | catches deterministic output regressions |
| Change detection tests | cache keys, affected-path matching, incremental rebuild | proves cache correctness |
| Golden tests | full generated fixture tree | protects output contracts |
| Consumer smoke tests | real app/package scripts | proves the actual integration path |
| Pack/install smoke tests | packed CLI works in a temp consumer | proves publish surface |
Good baseline commands
For the package itself:
bun run check-types
bun test
bun run buildbun run check-types
bun test
bun run buildFor a real consumer:
bun run check-types
registry-build buildbun run check-types
registry-build buildFor an installability check:
npm pack --dry-runnpm pack --dry-runGolden output strategy
Golden fixtures are the strongest regression net for this kind of package.
Use them when you need to detect:
- ordering changes
- emitted file name changes
- content rewrite regressions
- stale file cleanup regressions
- extension output drift
The most reliable pattern is:
- create a small fixture source tree
- run the full build into a temp output directory
- compare the generated files with checked-in expected outputs
Consumer CI example
bun run check-types
bun run build:reg
bun run buildbun run check-types
bun run build:reg
bun run buildThis keeps the generated registry path in the same pipeline as the app build that consumes it.
Release checklist
Package checks before publish
Make sure typecheck passes, tests pass, build output is generated cleanly, the packed tarball exposes the expected bin and exports, and a temp consumer can execute the installed CLI.
Consumer checks before rollout
Make sure the owning app or package can run registry-build build, a no-op warm build rewrites nothing, changed-only runs only touch the expected artifacts, and the downstream app build still passes with the generated files.
Debugging checks when something drifts
Compare generated outputs against the last known good tree, inspect the cache manifest under .registry-build/, run once with incremental: false if you need to rule out cache behavior, and prefer deterministic ordering in custom generators and extensions.
Production standard
The builder is not really production-ready until both the package and at least one real consumer are part of the same verification story.