Skip to content

chore: bump the target engine to v1.0.0-beta.10 - #34

Open
TomChv wants to merge 3 commits into
feat/runtime-execution-testsfrom
feat/bump-engine-beta10
Open

chore: bump the target engine to v1.0.0-beta.10#34
TomChv wants to merge 3 commits into
feat/runtime-execution-testsfrom
feat/bump-engine-beta10

Conversation

@TomChv

@TomChv TomChv commented Aug 21, 2026

Copy link
Copy Markdown
Member

Everything this repo ships is pinned to one engine release, so a bump moves four
things together, and skipping any of them is silent: the vendored library
sources, its generated bindings, the bundle built from them, and the Go
generator.

Re-vendored from the tag. beta.10 changes the library's introspector and its
registry, and adds agent to the module-facing index.ts — the same export whose
absence at beta.9 would have left modules unable to resolve it, caught again
here by the check that every re-export exists in the bundle.

The generator moved too, and three-way merged cleanly against our local changes:
@agent support in the entrypoint, nullable objects gated on a beta.10 cutover,
and the extendable-type list dropping Binding and Env. Left unsynced, that last
one would have generated augmentations for types the engine no longer has.

tsdistconsts is unchanged, so the typescript pin and bun image digest hold.

The workspace also pins sdk-sdk's CLI release to match. dagger/sdk-sdk#20 threads
the configured release through to the contract checks, which previously ran
mod-test's own pinned default and so paired this SDK's beta.10 bundle with a
beta.9 engine; all 22 contract-suite checks pass again. The pin stays even though
sdk-sdk's default matches ours today, because this SDK ships a library built for
one engine release, so the version the harness runs is load-bearing.

Also records what fork.withDirectory actually does. The client-bundle design
leaned on it being an overlay, which it is not: the polyfill documents it as
"add or replace" and the replace is real in the changeset's after tree. What
makes client regeneration safe is that a client changeset is only ever applied
to disk, and applying is additive. Module generation stages its changeset into a
workspace and reads it back, where unstaged files — the module's own config and
source — do disappear; hence the diff-based staging it uses instead. Verified
rather than reasoned: a client directory holding a vendored sdk/core.js and an
unrelated NOTES.md keeps both across a regeneration, with removedPaths empty.

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


Stack created with GitHub Stacks CLIGive Feedback 💬

TomChv added 3 commits August 25, 2026 18:04
Everything this repo ships is pinned to one engine release, so a bump moves
four things together, and skipping any of them is silent: the vendored library
sources, its generated bindings, the bundle built from them, and the Go
generator.

Re-vendored from the tag. beta.10 changes the library's introspector and its
registry, and adds `agent` to the module-facing index.ts — the same export whose
absence at beta.9 would have left modules unable to resolve it, caught again
here by the check that every re-export exists in the bundle.

The generator moved too, and three-way merged cleanly against our local
changes: `@agent` support in the entrypoint, nullable objects gated on a
beta.10 cutover, and the extendable-type list dropping Binding and Env. Left
unsynced, that last one would have generated augmentations for types the engine
no longer has.

tsdistconsts is unchanged, so the typescript pin and bun image digest hold.

sdk-sdk pins its own CLI release, which the workspace now overrides to match —
otherwise its harness pairs our beta.10 library with a beta.9 engine and every
scaffolded module fails to load.

Signed-off-by: Tom Chauveau <tom@dagger.io>
dagger/sdk-sdk#20 threads the configured CLI release through to the contract
checks, which previously ran mod-test's own pinned default and so paired this
SDK's beta.10 bundle with a beta.9 engine. All 22 contract-suite checks pass
again.

The workspace pin stays: sdk-sdk's default matches ours today, but this SDK
ships a library built for one engine release, so the version the harness runs
is load-bearing. Pinning states that, rather than inheriting whatever sdk-sdk
moves to next.

Signed-off-by: Tom Chauveau <tom@dagger.io>
The client-bundle design leaned on withDirectory being an overlay, which it is
not: the polyfill documents it as "add or replace" and the replace is real in
the changeset's after tree. What makes client regeneration safe is that a client
changeset is only ever applied to disk, and applying is additive.

That distinction is the difference between the two paths. Module generation
stages its changeset into a workspace and reads it back, where unstaged files —
the module's own config and source — do disappear; hence the diff-based staging
it uses instead.

Verified rather than reasoned: a client directory holding a vendored sdk/core.js
and an unrelated NOTES.md keeps both across a regeneration, with removedPaths
empty.

Signed-off-by: Tom Chauveau <tom@dagger.io>
@TomChv
TomChv force-pushed the feat/bump-engine-beta10 branch from 554d0c1 to e8eab51 Compare August 25, 2026 16:06
@TomChv
TomChv marked this pull request as ready for review August 25, 2026 16:15
@TomChv TomChv changed the title feat/bump engine beta10 chore: bump the target engine to v1.0.0-beta.10 Aug 25, 2026
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