Skip to content

Drop the polyfill for native workspace APIs - #30

Draft
grouville wants to merge 1 commit into
dagger:mainfrom
grouville:polyfill-removal
Draft

Drop the polyfill for native workspace APIs#30
grouville wants to merge 1 commit into
dagger:mainfrom
grouville:polyfill-removal

Conversation

@grouville

@grouville grouville commented Aug 7, 2026

Copy link
Copy Markdown
Member

The Go SDK no longer needs dagger/polyfill.

Managed modules come from currentModule.asSDK(workspace: ws).modules, using the registrations already present in dagger.toml. Generation now keeps the workspace it received, applies each module's generated files to it, then returns only the difference:

before := ws
after  := moduleSource.generate(before)
return after.changes(from: before)

That explicit baseline matters during module initialization: the input already contains the new config and scaffold, so the SDK sees those files without returning them a second time. Paths are made cwd-relative once, by Workspace.changes(from:).

Init, clients, and config edits use the same pattern, and the polyfill dependency is removed.

Test

dagger check 'e-2-e:*'

Requires dagger/dagger#13854 and dagger/dagger#13855.

The Go SDK used dagger/polyfill to discover managed modules, load module sources, stage generated files, and return only the changes made by one operation. The engine now provides those behaviors directly.

Use currentModule.asSDK(workspace).modules for managed modules, thread the resulting Workspace through generation, and compare the final workspace with the workspace the SDK received. Remove the polyfill and bump the engine requirement together so returned paths are translated exactly once.

Signed-off-by: Guillaume de Rouville <guillaume@dagger.io>
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