Skip to content

test(library): vendor the introspector's own test suite - #30

Draft
TomChv wants to merge 2 commits into
feat/codegen-test-coveragefrom
feat/library-tests
Draft

test(library): vendor the introspector's own test suite#30
TomChv wants to merge 2 commits into
feat/codegen-test-coveragefrom
feat/library-tests

Conversation

@TomChv

@TomChv TomChv commented Aug 12, 2026

Copy link
Copy Markdown
Member

Vendoring the library left its tests behind, so library/src had nothing
verifying it. The introspector's suite is the part that matters here: it scans
the fixture modules under testdata and compares against a recorded expectation,
which is the contract entrypoint generation rests on. Our own golden pins the
renderer given a typedef; nothing pinned the typedef given a module.

46 tests, run in the same bun container that builds the bundle.

The specs needing a live session (invoke, registry, api, connect) are left out:
they would need an engine inside the test container, and they cover the
library's runtime rather than anything this SDK generates.

Adding the test dependencies exposed that the build was not as reproducible as
claimed. A rebuild from an unchanged tree quietly gained transitive modules —
yarn.lock is a yarn v1 file that does not pin everything bun resolves. Both
lockfiles now sit in the tree and neither is redundant: dropping yarn.lock pulls
newer transitives and grows core.js by a quarter, while bun.lock pins what bun
actually installs. The install is frozen against it, so drift fails the install
instead of silently changing the bundle.

Signed-off-by: Tom Chauveau tom@dagger.io


Stack created with GitHub Stacks CLIGive Feedback 💬

TomChv added 2 commits August 19, 2026 16:33
Vendoring the library left its tests behind, so library/src had nothing
verifying it. The introspector's suite is the part that matters here: it scans
the fixture modules under testdata and compares against a recorded expectation,
which is the contract entrypoint generation rests on. Our own golden pins the
renderer given a typedef; nothing pinned the typedef given a module.

46 tests, run in the same bun container that builds the bundle.

The specs needing a live session (invoke, registry, api, connect) are left out:
they would need an engine inside the test container, and they cover the
library's runtime rather than anything this SDK generates.

Adding the test dependencies exposed that the build was not as reproducible as
claimed. A rebuild from an unchanged tree quietly gained transitive modules —
yarn.lock is a yarn v1 file that does not pin everything bun resolves. Both
lockfiles now sit in the tree and neither is redundant: dropping yarn.lock pulls
newer transitives and grows core.js by a quarter, while bun.lock pins what bun
actually installs. The install is frozen against it, so drift fails the install
instead of silently changing the bundle.

Signed-off-by: Tom Chauveau <tom@dagger.io>
The design credited the vendored yarn.lock for reproducibility, which turned
out to be half the story: it pins the resolved versions the sources came with,
but it is a yarn v1 file that does not pin everything bun resolves, and a
rebuild from an unchanged tree still drifted. Both lockfiles are needed and for
different reasons.

Signed-off-by: Tom Chauveau <tom@dagger.io>
@TomChv
TomChv force-pushed the feat/library-tests branch from 68702cd to 7013d0a Compare August 19, 2026 14:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant