test: add compile-time key-parity assertions for spec type checks#1652
Open
rechedev9 wants to merge 3 commits intomodelcontextprotocol:mainfrom
Open
test: add compile-time key-parity assertions for spec type checks#1652rechedev9 wants to merge 3 commits intomodelcontextprotocol:mainfrom
rechedev9 wants to merge 3 commits intomodelcontextprotocol:mainfrom
Conversation
Add 151 compile-time key-parity assertions to spec.types.test.ts that verify SDK and spec types have exactly the same set of named property keys. This catches missing .optional() parameters that the existing mutual-assignability checks cannot detect due to TypeScript structural subtyping. Introduces three utility types: - KnownKeys<T>: strips index signatures, keeps named keys only - AssertExactKeys<A, B>: resolves to true on match, descriptive error type on mismatch - Assert<T extends true>: constraint that forces compile error Coverage: 151 of 174 sdkTypeChecks entries. 23 exclusions documented (15 union types, 8 primitive aliases). Discovered 7 genuine SDK/spec key mismatches, documented with @ts-expect-error annotations as a living drift inventory. Closes modelcontextprotocol#1298
|
@modelcontextprotocol/client
@modelcontextprotocol/server
@modelcontextprotocol/express
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
Fix CI lint failure by applying Prettier formatting to the key-parity assertions test file.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
spec.types.test.tsthat catch missing/extra.optional()fields between SDK and spec typesKnownKeys<T>,AssertExactKeys<A,B>,Assert<T>) that produce descriptive compile errors on key-set mismatches@ts-expect-errorannotations (serving as a living drift inventory)sdkTypeChecksentries; 23 exclusions documented (union types and primitive aliases)Motivation
Closes #1298.
The existing mutual-assignability checks (
sdk = spec; spec = sdk) pass even when one type has optional keys that the other lacks, because TypeScript structural subtyping treats optional properties as compatible in both directions. This means a Zod schema missing.optional()on a field — or having.optional()when the spec requires the field — goes undetected.The new key-parity layer compares the exact set of named property keys between each SDK/spec type pair at compile time, with zero runtime cost.
Test plan
pnpm typecheck:allpasses (key-parity assertions validated at compile time)pnpm test:all— 734 tests pass (440 core + 37 server + 257 client)@ts-expect-errorannotations verified as necessary.optional()from a schema correctly triggers a compile error from the new assertions