feat: OSS SAST set up

[KKonstantinov]

This PR introduces test coverage scripts in package.json files that generates merged reports across all packages in the monorepo, along with SonarCloud integration for static application security testing (SAST) and code quality analysis. The new test:coverage:all command runs tests from the root and produces a single coverage report combining results from all packages, while individual packages can still generate their own coverage via test:coverage

Motivation and Context

Test Coverage Infrastructure:

Previously, there was no way to generate a unified coverage report across the monorepo. Each package could run tests independently, but aggregating coverage metrics for the entire codebase required manual effort. This change enables:

• Running coverage for all packages with a single command
• Generating merged HTML, JSON, and LCOV reports in ./coverage/
• Per-package coverage reports when needed

SAST/SonarCloud Integration:
Adds static application security testing via SonarCloud to the CI/CD pipeline. This provides:

• Automated security vulnerability detection
• Code smell and bug identification
• Technical debt tracking
• Coverage visualization in SonarCloud dashboard

How Has This Been Tested?

• Ran pnpm test:coverage:all from root — 478 tests pass with merged coverage report generated
• Verified coverage reports (HTML, JSON, LCOV) created in ./coverage/
• Tested individual package coverage with pnpm --filter <package> test:coverage

Breaking Changes

None. All changes are additive.

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

New scripts:

• test:coverage:all (root) — runs all tests with merged coverage
• test:coverage (per package) — runs coverage for individual package

Configuration changes:

• Added root vitest.config.js extending shared config via mergeConfig()
• Updated vitest.workspace.js to include examples/ and test/ directories
• Added coverage settings to common/vitest-config/vitest.config.js

New dependencies:

• @vitest/coverage-v8 — V8 coverage provider
• @modelcontextprotocol/vitest-config — added to root for config inheritance

SonarCloud setup:

• Added sonar-project.properties with project configuration
• Configured LCOV coverage report path for SonarCloud ingestion

[changeset-bot]

⚠️ No Changeset found

Latest commit: 481337f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

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

@modelcontextprotocol/server

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

@modelcontextprotocol/express

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

@modelcontextprotocol/hono

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

@modelcontextprotocol/node

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

commit: 481337f

[felixweinberger]

Thank you for your contribution to the MCP TypeScript SDK!

Suggestion: REQUEST_CHANGES

Comment: This PR adds valuable infrastructure for test coverage and SAST analysis. However, there are several issues that need to be addressed before merging:

Critical Issues

1. Missing SONAR_TOKEN Secret Setup

The sast job is currently skipping on this PR because it requires a SONAR_TOKEN secret that doesn't exist yet. The PR description should document the setup steps required by maintainers to configure:

• Creating a SonarCloud project
• Adding the SONAR_TOKEN repository secret

Without this, the new CI job will silently skip on all PRs.

2. Hardcoded Project Version

In sonar-project.properties:

sonar.projectVersion=2.0.0-alpha.0

This version will become stale immediately. Consider either:

• Removing this line (SonarCloud can work without it)
• Dynamically reading it from package.json in the workflow

3. Missing fetch-depth: 0 for SonarCloud

The SonarCloud documentation recommends using fetch-depth: 0 in the checkout step for proper blame information:

- uses: actions/checkout@v6
  with:
    fetch-depth: 0

4. sast Job Not in publish Dependencies

The publish job depends only on [build, test] but not sast. If SAST analysis is intended to be a quality gate, consider adding it to the dependencies:

needs: [build, test, sast]

Minor Issues

5. Reports Directory Potentially Created in Wrong Location

The sonar reporter outputs to reports/sonar-report.xml (relative to package), but the sonar-project.properties expects it at ./reports/sonar-report.xml (relative to root). Verify this works correctly when running from the root.

6. Coverage Includes Examples but SonarCloud Excludes Them

The root vitest.config.js includes examples/**/src/**/*.ts in coverage, but sonar-project.properties only sources from packages/. This is inconsistent—either include examples in SonarCloud or exclude them from coverage collection.

Questions

1. Has the SonarCloud project been created at https://sonarcloud.io for modelcontextprotocol_typescript-sdk?

2. Is there a plan for setting up the SONAR_TOKEN secret? This typically requires org admin access.

3. Why add vitest-sonar-reporter to the shared vitest config rather than only in the root config? Individual packages running test:coverage locally won't benefit from SonarCloud reporting.

---

The coverage infrastructure itself looks well-designed. The separation of per-package and root-level coverage is a good pattern. Please address the issues above and this will be ready for approval.