Repository navigation
fix(connectors): make the native specifiers opaque to a bundler - #266
Merged
Merged
Conversation
0.53.42 moved both native clients behind await import(), which is not enough: a bundler resolves a LITERAL dynamic import exactly like a static one. It moves the module into its own chunk and still has to load duckdb.node. Measured on legal-agent, whose Worker build failed on the same two files after the lazy change. The specifier is now assembled at runtime, so a bundler cannot read it and leaves the import to the runtime. Node resolves it; a Worker bundle never sees it. The guard test now fails on a literal dynamic import too, and strips comments first so the sentence explaining the rule is not read as a breach of it.
tangletools
approved these changes
Aug 9, 2026
tangletools
left a comment
Collaborator
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — d62b9354
This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.
tangletools · auto-approval · reason: drewstone_author · 2026-08-09T23:59:40Z
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.
#264 was necessary and not sufficient. Moving both native clients behind
await import()does not remove them from a bundle: a bundler resolves a literal dynamic import exactly like a static one — it moves the module into its own chunk and still has to loadduckdb.node.Measured on legal-agent against the published 0.53.42:
The static graph from
/catalog+/specswas already clean at that version — the walk proves it — and the build still failed, which is the whole lesson: a clean static graph is not the same as a bundle that links.The specifier is now assembled at runtime, so no bundler can read it and the import is left to the runtime. Node resolves it; a Worker bundle never sees it.
Proven on the real consumer before publishing: patching the same transformation into legal-agent's installed
0.53.42copy turned its build from the two errors above to✓ built in 4.86s / ✓ built in 6.35s.Guard
src/worker-safe-subpaths.test.tsnow fails on a literal dynamic import as well as a static one, and strips comments first — the prose explaining the rule was otherwise reported as a breach of it:typeof import('…')is excluded by lookbehind: a type query erases, which is how both adapters keep full typing while loading through an opaque specifier.Suite: 686 files / 5,161 tests passed.
pnpm typecheckexit 0,pnpm buildexit 0. Version bumped to 0.53.43 in the same change.