Skip to content

feat(packager): regenerate the TypeScript library bindings - #19

Draft
TomChv wants to merge 1 commit into
feat/codegen-module-modefrom
feat/codegen-library-mode
Draft

feat(packager): regenerate the TypeScript library bindings#19
TomChv wants to merge 1 commit into
feat/codegen-module-modefrom
feat/codegen-library-mode

Conversation

@TomChv

@TomChv TomChv commented Aug 10, 2026

Copy link
Copy Markdown
Member

The library ships its own generated bindings (src/api/client.gen.ts), and
vendoring the library here means owning their regeneration. Add the packager
module that does it, mirroring dagger/dagger's own clientLibrary generator.

The schema is the session's, not a module's: a plain session serves no modules,
so introspecting it yields the core API alone — unscrubbed, which is what a
library binds and what neither ModuleSource.introspectionSchemaJSON (scrubs
Host, currentWorkspace, ...) nor clientSchemaIntrospectionJSON (installs the
module it is called on) gives.

codegen introspect is the one subcommand that talks to the engine. It does so
over plain HTTP against the nested session rather than through the Go SDK, so
the generation subcommands keep their only inputs as files and pull in no
dependency; it also only ever runs in this repo's own generate step, never in a
user's.

The bindings land where the library source expects them, so vendoring the rest
of the library later drops in around them. On their own they do not compile —
the runtime they import (../common/context.js) arrives with that source.

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


Stack created with GitHub Stacks CLIGive Feedback 💬

The library ships its own generated bindings (src/api/client.gen.ts), and
vendoring the library here means owning their regeneration. Add the packager
module that does it, mirroring dagger/dagger's own clientLibrary generator.

The schema is the session's, not a module's: a plain session serves no modules,
so introspecting it yields the core API alone — unscrubbed, which is what a
library binds and what neither ModuleSource.introspectionSchemaJSON (scrubs
Host, currentWorkspace, ...) nor clientSchemaIntrospectionJSON (installs the
module it is called on) gives.

`codegen introspect` is the one subcommand that talks to the engine. It does so
over plain HTTP against the nested session rather than through the Go SDK, so
the generation subcommands keep their only inputs as files and pull in no
dependency; it also only ever runs in this repo's own generate step, never in a
user's.

The bindings land where the library source expects them, so vendoring the rest
of the library later drops in around them. On their own they do not compile —
the runtime they import (../common/context.js) arrives with that source.

Signed-off-by: Tom Chauveau <tom@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