Describe the bug
The published @modelcontextprotocol/sdk npm tarball ships dist/**/*.js.map source maps whose sources field references ../../../../src/**/*.ts, but the src/ directory is not included in the published package. Any bundler that resolves source maps (e.g. webpack's source-map-loader) fails to read the referenced TypeScript files and emits a warning for every SDK file it touches.
Verified on @modelcontextprotocol/sdk@1.29.0.
To Reproduce
Steps to reproduce the behavior:
- Install
@modelcontextprotocol/sdk@1.29.0 in a project bundled with webpack and source-map-loader enabled (the default for @nx/webpack Node apps with sourceMap: true).
- Import something from
@modelcontextprotocol/sdk — e.g. anything that pulls in dist/cjs/experimental/tasks/helpers.js.
- Run the build.
Inspecting the shipped map confirms the dangling reference:
// dist/cjs/experimental/tasks/helpers.js.map
{"version":3,"file":"helpers.js","sources":["../../../../src/experimental/tasks/helpers.ts"], ...}
The tarball contents:
package.json // no "files" field
LICENSE
README.md
dist/ // shipped
src/ // NOT shipped
Every dist/**/*.js.map in the package has the same broken sources path, so any imported file can trigger this — the experimental tasks helpers happened to surface it for us.
Expected behavior
The shipped source maps resolve cleanly. Either the referenced src/ files are included in the tarball, or the sources are inlined into the maps (sourcesContent / --inlineSources), or the maps are not shipped at all.
Logs
WARNING in .../@modelcontextprotocol/sdk/dist/cjs/experimental/tasks/helpers.js
Module Warning (from .../source-map-loader/dist/cjs.js):
Failed to parse source map from '.../@modelcontextprotocol/sdk/src/experimental/tasks/helpers.ts'
file: Error: ENOENT: no such file or directory, open
'.../@modelcontextprotocol/sdk/src/experimental/tasks/helpers.ts'
WARNING in .../@modelcontextprotocol/sdk/dist/cjs/experimental/tasks/interfaces.js
Module Warning (from .../source-map-loader/dist/cjs.js):
Failed to parse source map from '.../@modelcontextprotocol/sdk/src/experimental/tasks/interfaces.ts'
file: Error: ENOENT: no such file or directory, open
'.../@modelcontextprotocol/sdk/src/experimental/tasks/interfaces.ts'
WARNING in .../@modelcontextprotocol/sdk/dist/cjs/experimental/tasks/mcp-server.js
Module Warning (from .../source-map-loader/dist/cjs.js):
Failed to parse source map from '.../@modelcontextprotocol/sdk/src/experimental/tasks/mcp-server.ts'
file: Error: ENOENT: no such file or directory, open
'.../@modelcontextprotocol/sdk/src/experimental/tasks/mcp-server.ts'
Additional context
Possible fixes (any one resolves it):
- Add
"src" to the files array in package.json so the referenced TypeScript sources ship alongside the maps.
- Build with
--inlineSources (or post-process the maps to populate sourcesContent) so consumers don't need src/ on disk — typically the cleanest option for a published library.
- Strip the
//# sourceMappingURL= comments and omit .js.map files if maps aren't intended for downstream consumption.
Happy to open a PR for whichever direction maintainers prefer.
Describe the bug
The published
@modelcontextprotocol/sdknpm tarball shipsdist/**/*.js.mapsource maps whosesourcesfield references../../../../src/**/*.ts, but thesrc/directory is not included in the published package. Any bundler that resolves source maps (e.g. webpack'ssource-map-loader) fails to read the referenced TypeScript files and emits a warning for every SDK file it touches.Verified on
@modelcontextprotocol/sdk@1.29.0.To Reproduce
Steps to reproduce the behavior:
@modelcontextprotocol/sdk@1.29.0in a project bundled with webpack andsource-map-loaderenabled (the default for@nx/webpackNode apps withsourceMap: true).@modelcontextprotocol/sdk— e.g. anything that pulls indist/cjs/experimental/tasks/helpers.js.Inspecting the shipped map confirms the dangling reference:
The tarball contents:
Every
dist/**/*.js.mapin the package has the same brokensourcespath, so any imported file can trigger this — the experimental tasks helpers happened to surface it for us.Expected behavior
The shipped source maps resolve cleanly. Either the referenced
src/files are included in the tarball, or the sources are inlined into the maps (sourcesContent/--inlineSources), or the maps are not shipped at all.Logs
Additional context
Possible fixes (any one resolves it):
"src"to thefilesarray inpackage.jsonso the referenced TypeScript sources ship alongside the maps.--inlineSources(or post-process the maps to populatesourcesContent) so consumers don't needsrc/on disk — typically the cleanest option for a published library.//# sourceMappingURL=comments and omit.js.mapfiles if maps aren't intended for downstream consumption.Happy to open a PR for whichever direction maintainers prefer.