Skip to content

Fix: Barrel file exports #870

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Fix: Barrel file exports #870

wants to merge 5 commits into from

Conversation

KKonstantinov
Copy link
Contributor

Extension to #851 and #511

Motivation and Context

The SDK currently exports from all files, which leads to users/implementors having to import from multiple places from the SDK.

Example:

import { StreamableHTTPServerTransport } from '@modelcontextprotocol/sdk/server/streamableHttp.js';
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { isInitializeRequest, LoggingLevelSchema, SetLevelRequestSchema } from '@modelcontextprotocol/sdk/types.js';

This PR introduced index.ts barrel files under the following namespaces:

  • @modelcontextprotocol/sdk/server
  • @modelcontextprotocol/sdk/client
  • @modelcontextprotocol/sdk/shared (a new export added to package.json)

The above snippet would now look like:

import { StreamableHTTPServerTransport, McpServer } from '@modelcontextprotocol/sdk/server';
import { isInitializeRequest, LoggingLevelSchema, SetLevelRequestSchema } from '@modelcontextprotocol/sdk/shared';

How Has This Been Tested?

Unit tests continue to run with no issues.

Breaking Changes

No, it's an improvement and not a breaking change.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

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

Additional context

There are two files which were a bit controversial "./types.ts", and "./inMemory.ts". These are currently residing at the root level, although they are really "shared". Thus the shared namespace is re-exporting them.

Additionally, the previous client/index.ts contents was moved to client/client.ts and server/index.ts was moved to server/server.ts respectively. Since these two files are now re-exported by the index.ts files, there is no breaking change.

@KKonstantinov KKonstantinov requested review from a team as code owners August 12, 2025 19:09
@KKonstantinov KKonstantinov mentioned this pull request Aug 12, 2025
Merged
9 tasks
@KKonstantinov
Copy link
Contributor Author

KKonstantinov commented Aug 12, 2025 •
edited
Loading

@cliffhall @ihrpr this is an extension to #851

@cliffhall
Copy link
Member

cliffhall commented Aug 12, 2025 •
edited
Loading

This looks good to me in this view. One important thing for reviewers to do is make certain that the new server.ts and client.ts files contain exactly what their previous index.ts counterparts previously did. This is hard to do in the Files Changed diff view. It will have to be done locally in the IDE comparing to the historical content. I would do this now, but I have to prepare for a meeting.

@ihrpr ihrpr added this to the v2 milestone Aug 18, 2025
@ihrpr
Copy link
Contributor

ihrpr commented Aug 18, 2025

Let's include it in V2

@ihrpr ihrpr mentioned this pull request Aug 18, 2025
Open
@cliffhall
Copy link
Member

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

@ihrpr
Copy link
Contributor

ihrpr commented Aug 19, 2025

Let's include it in V2

@ihrpr maybe we could add a v2-feature label for PRs like this one.

I'm marking those PRs with V2 milestone

@joelachance
Copy link

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

@KKonstantinov
Copy link
Contributor Author

I have to say I was thinking of /sdk/types myself before comitting...

But if you do look at it, it really isn't just types that's in there.

The current sdk v1 unfortunately mixes types and runtime code in files. So even in your types.ts you will find runtime code.

And other files that are exported (from the shared folder) certainly have loads of runtime (and id say much more runtime than types)

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I came here to open this PR :)

Thanks for doing this.
One suggestion, it's not clear to me what would be contained in 'shared'. Are those all types? If that's the case, I'd argue to continue using '/sdk/types'

@joelachance
Copy link

Exporting something via /sdk/types "implies" as a user I would be able to put that in devDependencies let's say, or alternatively to be importing it via "import type * from @modelcontextprotocol/sdk/types". However its not the case here due to the majority of the code being runtime and not just types..

We could, still decide to do it via /sdk/types however I dont think the regular user will expect that, given what it actually contains. (Classes, schemas, methods etc. as opposed to the expectation implied which is it should be just types, interfaces etc)

I have seen types 'mixed in' with everything else in other libraries, but I'm not sure I like it. There's no indicators (that I know of) that give you the hint that you could pull in something like:

import { type LoggingLevelSchema } from '@mcp/sdk'

To your point, and maybe eventually, there is an sdk/types but it only contains types and interfaces, and the rest to live in a /runtime or /shared.

Anyway, I'm not sure I have a horse in this race, but glad it's being worked on :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@pcarleton pcarleton Awaiting requested review from pcarleton pcarleton is a code owner automatically assigned from modelcontextprotocol/typescript-sdk-auth

@felixweinberger felixweinberger Awaiting requested review from felixweinberger felixweinberger is a code owner automatically assigned from modelcontextprotocol/typescript-sdk

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
v2
Development

Successfully merging this pull request may close these issues.
4 participants
@KKonstantinov @cliffhall @ihrpr @joelachance