feat(codegen): generate module bindings - #18
Draft
TomChv wants to merge 1 commit into
Draft
Conversation
Add a `module` subcommand alongside `client`. Same generator, different contract: the module's own types stay in client.gen.ts, only its dependencies split into per-module files, and the bindings import the bundled library from ./core.js. The engine runtime mounts a module's sdk/ directory as @dagger.io/dagger, so the files are emitted flat into --output for the caller to lay down there — upstream nested them under sdk/src/api only to dig them back out again. The mode now drives what used to be independent config, so the two cannot disagree: bundle imports are implied by module codegen, and the source-map breadcrumbs rendered beside declarations resolve one level up from sdk/ rather than the three the old nesting needed. Drop the surface a TypeScript-only, engine-free generator never reads: the SDKLang enum and Config.Lang, the Generator interface (one implementation, one caller), GenerateTypeDefs (unimplemented), PostCommands and NeedRegenerate (Go-only), and the module config fields that only ever fed the Go generator. Design doc for the wider move included as design/module-gen.md. Signed-off-by: Tom Chauveau <tom@dagger.io>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add a
modulesubcommand alongsideclient. Same generator, differentcontract: the module's own types stay in client.gen.ts, only its dependencies
split into per-module files, and the bindings import the bundled library from
./core.js. The engine runtime mounts a module's sdk/ directory as
@dagger.io/dagger, so the files are emitted flat into --output for the caller
to lay down there — upstream nested them under sdk/src/api only to dig them
back out again.
The mode now drives what used to be independent config, so the two cannot
disagree: bundle imports are implied by module codegen, and the source-map
breadcrumbs rendered beside declarations resolve one level up from sdk/ rather
than the three the old nesting needed.
Drop the surface a TypeScript-only, engine-free generator never reads: the
SDKLang enum and Config.Lang, the Generator interface (one implementation, one
caller), GenerateTypeDefs (unimplemented), PostCommands and NeedRegenerate
(Go-only), and the module config fields that only ever fed the Go generator.
Design doc for the wider move included as design/module-gen.md.
Signed-off-by: Tom Chauveau tom@dagger.io
Stack created with GitHub Stacks CLI • Give Feedback 💬