Skip to content

Migrate to vitest from jest - #1074

Merged
pcarleton merged 12 commits into
modelcontextprotocol:mainfrom
mattzcarey:migrate-to-vitest
Nov 14, 2025
Merged

Migrate to vitest from jest#1074
pcarleton merged 12 commits into
modelcontextprotocol:mainfrom
mattzcarey:migrate-to-vitest

Conversation

@mattzcarey

@mattzcarey mattzcarey commented Nov 3, 2025

Copy link
Copy Markdown
Contributor

its newer, faster, works natively with the modern toolchain like typescript.

Motivation and Context

How Has This Been Tested?

Breaking Changes

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

@mattzcarey
mattzcarey requested review from a team as code owners November 3, 2025 21:51
@mattzcarey

Copy link
Copy Markdown
Contributor Author

The main motivation to do this is that vitest works with ESM modules natively. This means we can use MSW to test MCP servers more effectively. MSW is a lovely tool and is pretty much standard practise when testing typescript servers.

@KKonstantinov

KKonstantinov commented Nov 10, 2025

Copy link
Copy Markdown
Contributor

Fully support this. Was discussed in #1015 and #916 but not progressed. Additionally other repos are already migrating (e.g. modelcontextprotocol/servers#2884). It only makes sense that we do it here too!

@felixweinberger

Copy link
Copy Markdown
Contributor

Support shipping this as this seems like a pareto improvement. Looks like there are some conflicts to resolve.

Looking at CI:

CleanShot 2025-11-11 at 19 26 00

Not sure if these 2 are stalling because of this PR

@mattzcarey mattzcarey reopened this Nov 13, 2025
@pkg-pr-new

pkg-pr-new Bot commented Nov 13, 2025

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/sdk@1074

commit: 6dba08f

Comment thread src/server/streamableHttp.test.ts Outdated

@pcarleton pcarleton left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall looks good, ty for doing this. just had 2 questions about parts i didn't understand

Comment thread src/client/auth.test.ts
Comment thread src/server/streamableHttp.test.ts Outdated
mattzcarey and others added 3 commits November 13, 2025 15:26
Replace remaining Jest-specific APIs with Vitest equivalents:
- jest.Mock -> Mock (already imported from vitest)
- jest.fn() -> vi.fn()
- Add non-null assertion for TypeScript strict null check
@felixweinberger

Copy link
Copy Markdown
Contributor

@mattzcarey pushed a fix for the failing CI
@pcarleton ready for a stamp

@pcarleton
pcarleton merged commit 98df118 into modelcontextprotocol:main Nov 14, 2025
6 checks passed
@morozow

morozow commented May 4, 2026

Copy link
Copy Markdown

I also noticed that Vitest is used across several repositories, and that there was a migration from Jest to Vitest. I left a more detailed comment in the server repository here: modelcontextprotocol/servers#2884 (comment)
I recommend reconsidering this decision carefully, because there are potential stability and diagnostic concerns that should be reviewed before this pattern spreads further across repositories. The async/generator/mocked-function behavior mentioned there is only one small example of the broader concern. It should not be treated as the only reason. The main point is that Vitest can introduce different runtime and diagnostic behavior compared to Jest, and these differences may affect agents and developers who need stable, predictable test execution and clear failure signals.
For worldwide projects, including OSS projects, I would prefer to keep the test flow on Jest unless Vitest behavior is explicitly validated against these kinds of edge cases.

@morozow

morozow commented May 10, 2026

Copy link
Copy Markdown

This migration introduced vite as a mandatory peer dep of vitest. The currently locked vite@7.3.0 has two high-severity CVEs (GHSA-v2wj-q39q-566r, GHSA-p9ff-h696-f583), patched in ≥7.3.2. pnpm.overrides does not force the resolution for peer deps, so pnpm audit --audit-level=high fails on a clean checkout with no workaround short of adding vite as an explicit devDependency. Jest didn't have this problem — no bundler in the dep tree.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants