Skip to content

Drop the polyfill for native workspace APIs - #14

Merged
eunomie merged 2 commits into
dagger:mainfrom
grouville:polyfill-removal
Aug 20, 2026
Merged

Drop the polyfill for native workspace APIs#14
eunomie merged 2 commits into
dagger:mainfrom
grouville:polyfill-removal

Conversation

@grouville

@grouville grouville commented Aug 7, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

sdk-sdk used dagger/polyfill indirectly through the module-source type returned by its harness.

The harness now returns the native ModuleSource, so aliases such as workspaceView and sourceRootPath become their native equivalents, contextDirectory and sourceRootSubpath. The contract tests otherwise keep the same behavior and now exercise the path every migrated SDK uses.

Test

dagger check

@grouville grouville mentioned this pull request Aug 7, 2026
Closed
TomChv
TomChv reviewed Aug 12, 2026
View reviewed changes
Comment thread harness.dang
pub sdkTarget(ws: Workspace!): SdkTarget! {
let module = sdkModule(ws)
target(module.workspaceView, module.sourceRootPath)
target(module.contextDirectory, module.sourceRootSubpath)

@TomChv TomChv Aug 12, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand that change, it was already using the native API, why this part changes?

@grouville grouville Aug 12, 2026 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's surprising 😇

The polyfill usage is hidden in this line: let sdkModule(ws: Workspace!): PolyfillModuleSource!

So workspaceView and sourceRootPath were fields from the polyfill wrapper PolyfillModuleSource.

Now sdkModule returns a native ModuleSource, whose equivalents are contextDirectory and sourceRootSubpath.

No behavior change was intended, just converting the types

@TomChv TomChv Aug 13, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay lgtm then!

Comment thread harness.dang
view.withFile("dagger.json", view.file(module.sourceRootSubpath + "/dagger.json"))
} else {
view.withFile("dagger-module.toml", view.file(module.sourceRootPath + "/dagger-module.toml"))
view.withFile("dagger-module.toml", view.file(module.sourceRootSubpath + "/dagger-module.toml"))

@TomChv TomChv Aug 12, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, we're not using the polyfill module is this function so why does it changes? is there a bug in the sdk-sdk module?

@grouville grouville Aug 12, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above

@TomChv
TomChv marked this pull request as ready for review August 13, 2026 13:10
eunomie
eunomie requested changes Aug 20, 2026
View reviewed changes

@eunomie eunomie left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checks are not passing on my side (as well as if I replay them on the CI)
Holding the merge until we figure out what's wrong (working on it atm)

grouville and others added 2 commits August 20, 2026 15:41
@grouville @eunomie
Remove the polyfill dependency
9725eac 
The SDK test harness only needed the polyfill wrapper to turn a Workspace module source into its context directory and source-root path.

Use Workspace.moduleSource directly and replace the wrapper aliases with ModuleSource.contextDirectory and sourceRootSubpath. The behavior is unchanged; the engine bump and dependency removal land together.

Signed-off-by: Guillaume de Rouville <guillaume@dagger.io>
@eunomie
docs: use the native module-source fields in the harness example
7e7c463 
The polyfill removal renamed workspaceView/sourceRootPath to the native
contextDirectory/sourceRootSubpath everywhere except this README snippet,
which still showed callers the aliases that no longer exist.

Signed-off-by: Yves Brissaud <yves@dagger.io>
@eunomie
eunomie merged commit 00bb067 into dagger:main Aug 20, 2026
26 checks passed
eunomie added a commit to eunomie/python-sdk that referenced this pull request Aug 20, 2026
@eunomie
chore: update sdk-sdk to the polyfill-free harness
4c6fb5c 
sdk-sdk reached dagger/polyfill through the module-source type its harness
returned, which stopped working when the engine moved to v1.0.0-beta.10 and
took seven of this repository's checks down with it. dagger/sdk-sdk#14 replaced
it with the native ModuleSource; this records that version.

The lock file moves to format 2 as a side effect of being rewritten by the
current CLI.

Signed-off-by: Yves Brissaud <yves@dagger.io>
eunomie added a commit to eunomie/python-sdk that referenced this pull request Aug 21, 2026
@eunomie
chore: update sdk-sdk to the polyfill-free harness
3446596 
sdk-sdk reached dagger/polyfill through the module-source type its harness
returned, which stopped working when the engine moved to v1.0.0-beta.10 and
took seven of this repository's checks down with it. dagger/sdk-sdk#14 replaced
it with the native ModuleSource; this records that version.

The lock file moves to format 2 as a side effect of being rewritten by the
current CLI.

Signed-off-by: Yves Brissaud <yves@dagger.io>
eunomie added a commit to grouville/python-sdk that referenced this pull request Aug 21, 2026
@eunomie
chore: update sdk-sdk to the polyfill-free harness
05af0b2 
sdk-sdk reached dagger/polyfill through the module-source type its harness
returned, and its checks drove a CLI release older than the engine this module
now requires. Either one takes seven of this repository's checks down.
dagger/sdk-sdk#14 replaced the module-source type and dagger/sdk-sdk#20 taught
every check group to honor daggerCliVersion; this records that version.

The workspace floats sdk-sdk to its default branch, so the lock file is a record
rather than a constraint. It moves to format 2 as a side effect of being
rewritten by the current CLI, and loses the polyfill entry along with the
dependency.

Signed-off-by: Yves Brissaud <yves@dagger.io>
eunomie added a commit to grouville/php-sdk that referenced this pull request Aug 21, 2026
@eunomie
chore: update sdk-sdk to 00bb067
85e5b6f 
The pinned revision carried `daggerCliVersion = "1.0.0-beta.9"`, and a
beta.9 CLI cannot drive a beta.10 engine: beta.10 moved registering a
function's required `Workspace` argument as a CLI flag out of the engine and
into the CLI, so the older CLI never sees `initModule` at all and the
contract checks fail with `unknown command "init-module"`. sdk-sdk fixed its
own pin in dagger/sdk-sdk#14; picking it up here keeps the black-box checks
on the same release this module's engineVersion now requires.

Signed-off-by: Yves Brissaud <yves@dagger.io>
@eunomie eunomie mentioned this pull request Aug 21, 2026
Merged
eunomie added a commit to grouville/php-sdk that referenced this pull request Aug 21, 2026
@eunomie
chore: pin sdk-sdk to 00bb067
897ba97 
The committed lock was still in the v1 format, whose `float` entry the current
CLI no longer honors: every run silently re-resolved sdk-sdk to whatever main
pointed at and rewrote the file. Recording it in v2 makes the revision the
checks actually run against explicit again.

Pinning it at `00bb067` also matters for what it contains. The old entry named
`e1747f4`, which still declared `daggerCliVersion = "1.0.0-beta.9"`, and a
beta.9 CLI cannot drive a beta.10 engine — beta.10 moved registering a
function's required `Workspace` argument as a CLI flag out of the engine and
into the CLI, so the older CLI never sees `initModule` and the contract checks
fail with `unknown command "init-module"`. sdk-sdk fixed its own pin in
dagger/sdk-sdk#14; `00bb067` is that fix, and it keeps the black-box checks on
the release this module's engineVersion now requires.

Signed-off-by: Yves Brissaud <yves@dagger.io>
eunomie added a commit to grouville/php-sdk that referenced this pull request Aug 21, 2026
@eunomie
chore: pin sdk-sdk to 3344489
87b6c33 
The committed lock was still in the v1 format, whose `float` entry the current
CLI no longer honors: every run silently re-resolved sdk-sdk to whatever main
pointed at and rewrote the file. Recording it in v2 makes the revision the
checks actually run against explicit again.

Pinning it here also matters for what it contains. The old entry named
`e1747f4`, which still declared `daggerCliVersion = "1.0.0-beta.9"`, and a
beta.9 CLI cannot drive a beta.10 engine — beta.10 moved registering a
function's required `Workspace` argument as a CLI flag out of the engine and
into the CLI, so the older CLI never sees `initModule` and the contract checks
fail with `unknown command "init-module"`. dagger/sdk-sdk#14 fixed that pin,
and dagger/sdk-sdk#17 then added the `monorepo` group, which drives a workspace
whose dagger.toml sits in a git subdirectory — the layout where module paths
cross the engine/SDK boundary root-relative while the selected config reads
them relative to itself. That is exactly what this module's path anchoring has
to get right, so it is worth being on.

Signed-off-by: Yves Brissaud <yves@dagger.io>
eunomie added a commit to grouville/php-sdk that referenced this pull request Aug 21, 2026
@eunomie
chore: pin sdk-sdk to 3344489
9f3ed90 
The committed lock was still in the v1 format, whose `float` entry the current
CLI no longer honors: every run silently re-resolved sdk-sdk to whatever main
pointed at and rewrote the file. Recording it in v2 makes the revision the
checks actually run against explicit again.

Pinning it here also matters for what it contains. The old entry named
`e1747f4`, which still declared `daggerCliVersion = "1.0.0-beta.9"`, and a
beta.9 CLI cannot drive a beta.10 engine — beta.10 moved registering a
function's required `Workspace` argument as a CLI flag out of the engine and
into the CLI, so the older CLI never sees `initModule` and the contract checks
fail with `unknown command "init-module"`. dagger/sdk-sdk#14 fixed that pin,
and dagger/sdk-sdk#17 then added the `monorepo` group, which drives a workspace
whose dagger.toml sits in a git subdirectory — the layout where module paths
cross the engine/SDK boundary root-relative while the selected config reads
them relative to itself. That is exactly what this module's path anchoring has
to get right, so it is worth being on.

Signed-off-by: Yves Brissaud <yves@dagger.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@eunomie eunomie eunomie approved these changes
@TomChv TomChv TomChv approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@grouville @eunomie @TomChv