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 build
For a real consumer:
bun run check-types
registry-build build
For an installability check:
npm pack --dry-run
Golden 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 build
This keeps the generated registry path in the same pipeline as the app build that consumes it.
Release checklist
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.