fix: add explicit .js extensions to relative imports so declarations resolve under NodeNext/Node16#705
Open
ken-jo wants to merge 1 commit into
Conversation
…resolve under NodeNext/Node16 The emitted .d.ts copy relative specifiers verbatim, and the extensionless form (e.g. `from "./events"`) doesn't resolve under Node16/NodeNext, hiding inherited members such as `addEventListener` (TS2339). Appending `.js` matches the existing SDK-import style and works with both bundler-mode type-checking and Bun.build. Types-only; runtime is unaffected. Fixes modelcontextprotocol#704
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.
Summary
Fixes #704.
The published type declarations use extensionless relative import specifiers (e.g.
import { ProtocolWithEvents } from "./events";indist/src/app-bridge.d.ts).tsc(emitDeclarationOnly) copies specifiers verbatim fromsrc, and underNode16/NodeNextmodule resolution a relative specifier must carry an explicit extension — so these imports don't resolve for downstream consumers. Any type that transitively depends on one loses its members; most visibly, the recommendedbridge.addEventListener("sandboxready", …)API (inherited fromProtocolWithEventsvia./events) becomes invisible, producingTS2339.This adds explicit
.jsextensions to every relative import/export specifier acrosssrc. It is types-only — runtime JavaScript is unaffected, since the.jsbundles are produced byBun.build, which inlines relative modules (no extensionless relative import survives at runtime). The change matches the existing external-SDK import style (e.g.@modelcontextprotocol/sdk/shared/protocol.js), which already uses explicit.js; only the relative imports were inconsistent. It is compatible with both the repo'sbundler-mode type-check andBun.build(both resolve./x.js→./x.ts). No bare package specifiers were touched.Verification
tsconfigwithmoduleResolution: NodeNextandindex.tsdoingbridge.addEventListener("sandboxready", () => {}), type-checked against a freshly builtdist:index.ts: error TS2339: Property 'addEventListener' does not exist on type 'AppBridge'.(tsc --noEmitexits 2)tsc --noEmitexits 0.npm run prettier— the changed files are clean.npm test— 373 pass, 2 skip, 0 fail (types-only change; no test behavior affected).Scope: 13 files, 35 relative specifiers under
src/**(including the*.test.tsrelative imports, for consistency).