feat: move TypeScript client codegen into the SDK module

[TomChv]

Move TypeScript client codegen into the SDK module

Moves TypeScript client generation out of dagger/dagger's engine runtime and into this .dang SDK module. The module now generates a typed client for a bound module itself — receiving the schema + module metadata from the engine as plain data and running codegen in an ordinary container, with no nested engine session.

Important

Depends on two engine PRs, both gated v1.0.0-0:

• feat(core): add client-codegen schema primitives (v1.0.0-0) dagger#13646 — the client-codegen schema primitives: ModuleSource.clientSchemaIntrospectionJSON (the client-facing schema: core + the bound module only) and CurrentModuleAsSDKClient.moduleSource (resolves the bound module at generation time, honoring pin/remote refs).
• feat(core): add Workspace.moduleSource to load a module from a workspace dagger#13663 — Workspace.moduleSource(path), the runtime field the generated client calls to serve its bound module from a plain connect() session (design: hack/designs/generated-client-module-loading.md).

This PR requires an engine that ships both.

What's in it

helpers/codegen — the TypeScript client generator ported from dagger/dagger's cmd/codegen as a standalone, engine-free Go module (no dagger.io/dagger dependency). Reads a pre-computed introspection schema + a meta.json (module name, engine version, bound module) and emits the client bindings. The upstream live-engine query is replaced by the meta.json input. Upstream golden tests ported to guard fidelity.

helpers/config-updator — new client config writers producing a scoped npm package: package.json (@dagger.io/<module>-client name, @dagger.io/dagger pinned to the engine version, type:module, typescript), plus tsconfig.json / deno.json.

typescript-sdk.dang — the dang wiring:

• generateClient(ws, module, path) — the workspace analogue of mod(ws, path).generate(ws).
• generateAllClient(ws) @generate — regenerates every registered client (currentModule.asSDK.clients), resolving each bound module via client.moduleSource and generating from clientSchemaIntrospectionJSON.
• Renamed generateAll → generateAllModule for symmetry.
• codegenBuilder / configUpdatorBuilder container builders (compiled like the existing helpers).

e2e — generateClientCheck, generateAllClientCheck, generateClientRespectsExistingCheck, generateClientCompilesCheck, and helperTestsCheck (runs the Go helper tests inside dagger check), plus dependency-bearing fixtures (client/app → client/dep).

Client output layout

A generated client is a scoped package:

• dagger.gen.ts — core Dagger types (named to match the Go SDK's dagger.gen.go)
• <module>.gen.ts — one per module: the bound module (e.g. hello.gen.ts) and each dependency; each carries its own types plus the prototype augmentations it contributes to Query/Client/Binding/Env.

Key design decisions

• Always Remote / scoped package — the client depends on the npm @dagger.io/dagger; no TypeScript library bundle is vendored here.
• Serve the one bound module — the client schema is core + the bound module only, so the generated serveBoundModule bootstrap serves exactly that module (no dependency loop, no includeDependencies). A LOCAL_SOURCE/DIR_SOURCE module is resolved against the workspace by its workspace-root-relative path (dag.currentWorkspace().moduleSource(path)) — cwd-independent, so it works anywhere in the project tree; a GIT_SOURCE module serves from its canonical ref + pin (dag.moduleSource(ref, { refPin })), which resolves from anywhere. A local-bound client shipped away from the project tree is unservable by design (remote-only) — see hack/designs/generated-client-module-loading.md.

Full rationale in design/client-gen.md.

Testing

• Go unit + golden tests: go test ./... in each helper (also run inside dagger check via helperTestsCheck), including a golden test for the serveBoundModule bootstrap (local path vs. git ref + pin).
• e2e checks green on the #13646 dev engine, except generateClientCompilesCheck, which additionally requires #13663: it type-checks the generated dag.currentWorkspace().moduleSource(...) against the engine's Workspace.moduleSource, so it only passes once the engine ships that field.

Known limitations / follow-ups

• @dagger.io/dagger version on a dev/unreleased engine isn't on npm. generateClientCompilesCheck builds it from a pinned dagger/dagger commit; the client's package.json respects an existing local ./sdk ref (see design/client-bundle.md).
• Deno client config exists in config-updator but isn't wired into clientDirectory yet.

[TomChv]

PR needs dagger/dagger#13646 merged and released in order to load

[TomChv]

Once dagger/dagger#13663 is merge, the typescript client codegen will work :D
I did a manual test and that works hehehe