Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Deno: TS2307 on all .js subpath imports — './*' exports map types to '*.js.d.ts'

オープン 初心者向け
#2,701 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
84/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
deno, typescript

調査の方向性

パッケージのエクスポートマップから始め、提供された mod.ts と deno check コマンドを使って失敗を再現します。Deno で .js サブパスパターンが宣言を解決することを確認し、その後、既存の tsc と Node のチェックが ./* エントリに影響を与えず引き続き成功することを確認します。

索引モデルが issue の本文から書いたものです。

説明

v1
Summary

Under Deno, every .js-suffixed subpath import of the SDK fails type resolution with TS2307, because the ./* export pattern maps types to ./dist/esm/*.d.ts. For the specifier @modelcontextprotocol/sdk/server/mcp.js, * captures server/mcp.js, so the types path resolves to dist/esm/server/mcp.js.d.ts — which does not exist. The real declaration file is dist/esm/server/mcp.d.ts.

tsc resolves this fine (it strips the .js before matching), so the problem is invisible to Node-only users. Deno applies the substitution literally and fails.

This affects the import style used throughout the SDK's own README and examples, so it hits essentially any MCP server that tries to type-check under Deno or publish to JSR.

Reproduction

Clean directory, no tsconfig:

mkdir repro && cd repro
echo '{"name":"repro","type":"module","dependencies":{"@modelcontextprotocol/sdk":"1.30.0"}}' > package.json
npm install
echo '{"nodeModulesDir":"manual"}' > deno.json
printf 'import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";\nexport const s: McpServer | null = null;\n' > mod.ts

deno check mod.ts

Result:

Check mod.ts
TS2307 [ERROR]: Cannot find module '@modelcontextprotocol/sdk/server/mcp.js'.
    at file:///.../repro/mod.ts:1:27
error: Type checking failed.

The identical file under tsc 5.9.3 exits 0:

tsc --noEmit --module nodenext --moduleResolution nodenext --strict mod.ts   # exit 0
Why it's worse than one error

Once McpServer is unresolved, the zod-inferred parameter types on every server.tool(...) callback collapse to any. In a real server this cascades: a file of mine with 3 SDK imports produced 1 × TS2307 plus 19 × TS7031 ("Binding element 'sessionId' implicitly has an 'any' type"), all downstream of the single resolution failure. The error output makes it look like a codebase problem rather than a one-line packaging one.

Versions
  • @modelcontextprotocol/sdk 1.30.0
  • Deno 2.9.0 (stable, x86_64-unknown-linux-gnu)
  • TypeScript 5.9.3
  • Node 24
Suggested fix

Add a ./*.js pattern alongside the existing ./*. Node's exports resolution prefers the more specific pattern, so ordering doesn't matter and existing consumers are unaffected:

"./*.js": {
  "types": "./dist/esm/*.d.ts",
  "import": "./dist/esm/*.js",
  "require": "./dist/cjs/*.js"
},
"./*": {
  "types": "./dist/esm/*.d.ts",
  "import": "./dist/esm/*",
  "require": "./dist/cjs/*"
}

I verified this against 1.30.0 by patching node_modules:

  • deno check mod.ts → exit 0
  • node --input-type=module -e 'import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; ...' → still resolves, typeof McpServer === "function"

So it fixes Deno without regressing Node.

Note on prior art

#1269 ("Non-Node environment support (Bun, Deno, React Native)") was closed as completed in March, but this type-resolution path appears not to be covered by it — runtime import works under Deno, only type-checking fails. Happy to open a PR if the suggested shape looks right.

主要言語
TypeScript
スター
13.6k
フォーク
2.3k
平均マージ
1日 18時間
マージ済み PR(30日)
54

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/typescript-sdk のほかの issue

modelcontextprotocol/typescript-sdk の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。