feat(library): vendor the TypeScript SDK library and build its bundle - #21
Draft
TomChv wants to merge 2 commits into
Draft
feat(library): vendor the TypeScript SDK library and build its bundle#21TomChv wants to merge 2 commits into
TomChv wants to merge 2 commits into
Conversation
Module bindings import their runtime from ./core.js, a bundle that until now only existed inside the engine image — which is why this repo could generate a module's bindings but not the library they run against. Vendor the library and build the bundle here instead. The source is dagger/dagger's sdk/typescript at v1.0.0-beta.9, the engine these checks run against, minus what does not belong to the library itself: the Go runtime module (which stays upstream), the test and lint tooling, the upstream changelog, and its dagger.json — a stray module config here would be discovered as a workspace module. src/api/client.gen.ts is left out too; the packager already generates it. libraryBundle builds core.js and core.d.ts with the same commands and the same pinned bun image as toolchains/engine-dev/build/sdk.go, so a module built against this bundle behaves like one built against the engine's. Verified: it exports the runtime the generated bindings import (Context, BaseClient) and the decorators modules are written with (object, func, field, enumType, entrypoint, ...). The bundle is committed rather than built on demand: the SDK reads it at generate time, and building it there would put a bun toolchain in the critical path of every `dagger generate`. Signed-off-by: Tom Chauveau <tom@dagger.io>
The vendored scripts all pointed at things this repo does not have: mocha, eslint and tsx were left behind with the tests they serve, and the docs scripts reach for ../../docs/current_docs. Only `build` was live, and the packager already runs tsc itself. Drop them, and trim devDependencies and resolutions to what the bundle build actually uses (rollup, rollup-plugin-dts, the @types the declaration build needs) so package.json describes the package while the packager owns how it is built. Keep yarn.lock: it is load-bearing, not vendored ceremony. Installing without it resolves newer transitives and grows core.js from 4.3 MB to 5.4 MB, so the bundle would silently stop matching the one the engine ships. 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.
Module bindings import their runtime from ./core.js, a bundle that until now
only existed inside the engine image — which is why this repo could generate a
module's bindings but not the library they run against. Vendor the library and
build the bundle here instead.
The source is dagger/dagger's sdk/typescript at v1.0.0-beta.9, the engine these
checks run against, minus what does not belong to the library itself: the Go
runtime module (which stays upstream), the test and lint tooling, the upstream
changelog, and its dagger.json — a stray module config here would be discovered
as a workspace module. src/api/client.gen.ts is left out too; the packager
already generates it.
libraryBundle builds core.js and core.d.ts with the same commands and the same
pinned bun image as toolchains/engine-dev/build/sdk.go, so a module built
against this bundle behaves like one built against the engine's. Verified: it
exports the runtime the generated bindings import (Context, BaseClient) and the
decorators modules are written with (object, func, field, enumType, entrypoint,
...).
The bundle is committed rather than built on demand: the SDK reads it at
generate time, and building it there would put a bun toolchain in the critical
path of every
dagger generate.Signed-off-by: Tom Chauveau tom@dagger.io
Stack created with GitHub Stacks CLI • Give Feedback 💬