feat(codegen): render the module entrypoint - #24
Draft
TomChv wants to merge 1 commit into
Draft
Conversation
Wire the entrypoint renderer, ported with the client codegen but never reachable, to a subcommand. Unlike the binding generators it never sees the schema: it works from the typedef JSON the SDK introspector emits by scanning the user's own source, which is what carries the per-declaration locations the dispatcher imports classes from. The golden is the introspector's real output, not hand-written JSON — captured by scanning a module that exercises what dispatch has to handle: a constructor with a defaulted argument, exposed fields (including an object one, which round-trips through an ID), an optional argument, an async method and a void return. Upstream has no test for this renderer at all, here or in dagger/dagger, so this is the first thing pinning it. Producing that fixture surfaced two constraints on how the compiler reaches the scanner, both now recorded in the design: it must be the full package, since a trimmed one loses lib/lib.*.d.ts and with it every global type (any module returning Promise<T> fails, confusingly, as "could not resolve type reference for string"); and it must sit next to introspector.js, since bare imports resolve from the importing file rather than the working directory. 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
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.
Wire the entrypoint renderer, ported with the client codegen but never
reachable, to a subcommand. Unlike the binding generators it never sees the
schema: it works from the typedef JSON the SDK introspector emits by scanning
the user's own source, which is what carries the per-declaration locations the
dispatcher imports classes from.
The golden is the introspector's real output, not hand-written JSON — captured
by scanning a module that exercises what dispatch has to handle: a constructor
with a defaulted argument, exposed fields (including an object one, which
round-trips through an ID), an optional argument, an async method and a void
return. Upstream has no test for this renderer at all, here or in
dagger/dagger, so this is the first thing pinning it.
Producing that fixture surfaced two constraints on how the compiler reaches the
scanner, both now recorded in the design: it must be the full package, since a
trimmed one loses lib/lib.*.d.ts and with it every global type (any module
returning Promise fails, confusingly, as "could not resolve type reference
for string"); and it must sit next to introspector.js, since bare imports
resolve from the importing file rather than the working directory.
Signed-off-by: Tom Chauveau tom@dagger.io
Stack created with GitHub Stacks CLI • Give Feedback 💬