Repository navigation
fix(sdk): keep per-API imports from pulling every API's docs into a bundle - #604
Merged
Merged
Conversation
…undle Importing one client, e.g. @epilot/sdk/pricing, made bundlers emit a lazy chunk for the docs and OpenAPI spec of every API (about 160 chunks, 5 MiB). client.help() and client.openapi() looked their files up by name through a glob import that lived in the chunk every per-API entry shares. Each @epilot/sdk/<api> entry now passes loaders with literal paths to its own two files. The by-name lookup stays for the root SDK only. help() and openapi() behave as before. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
anttiviljami
approved these changes
Nov 13, 2026
anttiviljami
left a comment
anttiviljami
left a comment
Member
There was a problem hiding this comment.
Nice one! Thanks @alexmarqs !
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.
Problem
Importing a single client, e.g.
@epilot/sdk/pricing, makes a bundler emit a lazy chunk for the docs and OpenAPI spec of every API in the SDK: about 160 chunks, 5 MiB of build output.client.help()andclient.openapi()look their files up by name (import(./docs/${name})). esbuild turns that into a glob map of every doc and definition, and that map sat in the chunk all@epilot/sdk/<api>entries share. The chunks only load if those methods are called, so users don't download them, but they bloat every consumer's build. Present in every version sampled from 2.5.0 to 2.20.106.Fix
Each
@epilot/sdk/<api>entry now passes loaders with literal paths to its own two files (src/api-docs.ts,lazyApiDocs).client-factoryno longer imports the by-name lookup; that stays for the root SDK only (epilot.help(name),epilot.openapi(name), and thehelp/openapiexports).help()andopenapi()behave as before on per-API clients and on the root SDK.src/apis/are regenerated from the updated template inscripts/generate-sdk-v2.ts.src/apis/target.tshas no client behind it any more (the API istargeting) but is still built, so it is updated by hand to keep the build passing.Measured
Same SDK version (2.20.106) built without and with the fix, dropped into two consumers' installed SDK, production webpack builds:
@epilot/address-suggestion)Initial JS is unchanged in both (these chunks were never loaded).
Tests
pnpm lintandpnpm testpass (368 tests).dist-integration.test.ts: every per-API dist entry may reach at most its own two lazy files; a per-API client still serveshelp()andopenapi()from the built package.Notes
src/definitions, soopenapi()already failed for them. It now throwsNo OpenAPI specification bundled for "<api>"instead of a module-not-found error. Not addressed here.🤖 Generated with Claude Code