feat(compat): re-export StreamableHTTPServerTransport + EventStore types from /node

[felixweinberger]

Part of the v2 backwards-compatibility series — see reviewer guide.

v2 renamed StreamableHTTPServerTransport → NodeStreamableHTTPServerTransport. v2 already kept the Options type alias (incoherent). This adds the class alias + EventStore/EventId/StreamId re-exports.

Motivation and Context

v2 renamed StreamableHTTPServerTransport → NodeStreamableHTTPServerTransport. v2 already kept the Options type alias (incoherent). This adds the class alias + EventStore/EventId/StreamId re-exports.

v1 vs v2 pattern & evidence

v1 pattern:

`import { StreamableHTTPServerTransport } from '@modelcontextprotocol/sdk/server/streamableHttp.js'`

v2-native:

`import { NodeStreamableHTTPServerTransport } from '@modelcontextprotocol/node'`

Evidence: GitHub code search: ~1,700 files.

How Has This Been Tested?

• Import-compiles test
• Integration: validated bump-only against 5 OSS repos via the v2-bc-integration validation branch
• pnpm typecheck:all && pnpm lint:all && pnpm test:all green

Breaking Changes

None.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added or updated documentation as needed

Additional context

Stacks on: none

[changeset-bot]

🦋 Changeset detected

Latest commit: e5af3b3

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@modelcontextprotocol/node	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/@modelcontextprotocol/client@1904

@modelcontextprotocol/server

npm i https://pkg.pr.new/@modelcontextprotocol/server@1904

@modelcontextprotocol/express

npm i https://pkg.pr.new/@modelcontextprotocol/express@1904

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/@modelcontextprotocol/fastify@1904

@modelcontextprotocol/hono

npm i https://pkg.pr.new/@modelcontextprotocol/hono@1904

@modelcontextprotocol/node

npm i https://pkg.pr.new/@modelcontextprotocol/node@1904

commit: e5af3b3

[claude]

LGTM — the force-push drops @deprecated to match the existing StreamableHTTPServerTransportOptions precedent, which resolves the bundler-stripping concern; remaining note on the PR description wording is non-blocking.

Extended reasoning...

Overview

Adds 7 lines to packages/middleware/node/src/index.ts: a v1-compat alias StreamableHTTPServerTransport → NodeStreamableHTTPServerTransport and type re-exports of EventStore/EventId/StreamId from @modelcontextprotocol/server. Ships with a vitest file asserting runtime identity (.toBe) and type-level exports (expectTypeOf), plus a changeset. No logic, no transport behaviour change — pure re-exports.

What changed since my last review

My earlier inline comment (on commit 3d48f5e) flagged that an @deprecated JSDoc on the export specifier was being stripped by tsdown's dts bundler. The author force-pushed e5af3b3, which resolves this by removing @deprecated entirely rather than restructuring to preserve it. The comment now reads "v1 name. The v2-preferred name is…", the "keep until v3" comment is gone, and the test no longer needs an eslint-disable. This is a valid resolution: it matches the pre-existing StreamableHTTPServerTransportOptions alias at streamableHttp.ts:22, which also carries no @deprecated. The new inline nit notes the only residual mismatch (PR description still says "@deprecated shim. Removed in v3"), but the changeset file — which is what actually ships in the CHANGELOG — makes no such claim and is accurate.

Security risks

None. Re-exporting an existing class under an additional name and re-exporting types has no runtime attack surface.

Level of scrutiny

Low. This is part of the labelled v2-bc series with an established reviewer guide, the pattern (un-deprecated compat alias) already exists in the same file for the Options type, and the additions are purely additive. The repo's "burden of proof on addition" principle is satisfied by the cited ~1,700 v1 call sites and the incoherence of shipping the Options alias without the class alias.

Other factors

Test coverage is appropriate for what's being added (identity + type-compiles). The earlier inline comment is now stale against the force-pushed diff; the new nit-level inline comment supersedes it and is informational only.