Drop the polyfill for native workspace APIs

[TomChv]

Reworks #16.

The TypeScript SDK depended on dagger/polyfill for three things: selecting the modules it manages, forking the workspace to stage edits, and re-rooting the resulting changeset into the client's cwd. All three are now native in the engine (dagger/dagger#13854, #13855), so the dependency goes.

Module selection. currentModule.asSDK(workspace:).modules returns this SDK's registered modules, workspace-root-relative, already narrowed by the engine to the client's cwd — everything at or below it, plus the nearest enclosing module when the cwd is not itself registered. That is exactly what the polyfill's findConfigDirs walk intersected with the workspace's managed-module list produced, so the walk, the intersection, and the cwd-to-root path mapping all go.

Changesets. #13855 set changesetCwdCutover = "v1.0.0-beta.10": past that module engine version the engine measures a Workspace.changes result from the workspace cwd itself, and fails loudly on a change that falls outside it. Declaring the version hands the re-rooting the polyfill's fork used to do back to the engine, and every staging site collapses to the shape #13855 was designed for — keep the baseline you already hold, derive, diff:

ws.withNewDirectory("/" + modPath, templateSource).changes(ws)

Paths are anchored at / because they are workspace-root-relative: a relative workspace path resolves from ws.cwd and would otherwise be prefixed a second time when a function is called directly from a subdirectory rather than driven by the engine.

Module sources now resolve through Workspace.moduleSource, which is the call the polyfill's core field was making. And ModuleSource.generate(workspace:) stages the module's local dependency closure itself, then applies only that module's own generated context to the workspace it was handed — so the explicit generateLocalDependencies staging around each codegen goes with it, in both Mod.generate and generateAllModule.

generateAll* keeps its concurrency, and the merge stays a changeset merge:

let changes = modules(ws)
  .filter { mod => mod.skipGenerate(ws) == false }
  .map { mod => ws.moduleSource("/" + mod.rootPath).generate(ws).changes(ws) }
changes.{{isEmpty}}
ws.changes(ws).withChangesets(changes)

Worth recording why, since the near-miss is easy to walk into: these per-module changesets are cwd-measured now, so they must not be folded by re-applying them to a workspace — Workspace.withChanges overlays at the workspace root, which is one frame off for every cwd but the root, and the engine's nested per-dependency generation runs at the dependency's cwd. Changeset.withChangesets merges the patches directly and never re-enters workspace coordinates, so operands and result are both cwd-measured — the frame the engine applies a returned generator changeset in. The empty fold seed no longer needs the polyfill's fork: ws.changes(ws) compares a workspace against itself, so it stays empty even when that nested workspace already carries a staged closure.

dagger.lock is what the beta.10 CLI writes: the v2 format, the container digests it resolved, and sdk-sdk floated to 00bb067, which picks up dagger/sdk-sdk#20 — the harness now runs its contract checks on the configured CLI release. Before it, a CLI older than beta.10 silently skipped every function taking a Workspace! argument, which is initModule and every generator here. It also brings a monorepo check group that did not run at all on the old pin.

Test

dagger --x-release=v1.0.0-beta.10 check

57/57. That includes sdk-sdk:generation:respects-cwd and sdk-sdk:chain:respects-cwd, which cover generating from a subdirectory — the case e2e:generate:generate-all-scope-check documents it cannot run itself and used to defer to the polyfill's own suite for.

Requires an engine at v1.0.0-beta.10 or newer, which the module now declares.