fix(api-compat): allow optional property additions to inline object literals#2036
Merged
Stephen Belanger (Qard) merged 1 commit intoMay 21, 2026
Merged
Conversation
…iterals areInterfaceSignaturesCompatible compared each property's type as a string, then only re-checked via isUnionTypeWidening when the strings differed. Adding an optional property to an inline object literal (e.g. mastra?: boolean to InstrumentationConfig.integrations) flips the string equality, isn't a union widening, and was incorrectly classified as a breaking change — even though it's structurally backward-compatible TypeScript. Fix: delegate to the existing areObjectTypeDefinitionsCompatible helper when both sides are inline object literals, mirroring the pattern already in areTypeAliasSignaturesCompatible. Also apply the same delegation inside areObjectTypeDefinitionsCompatible itself so nested object literals get the same treatment. Lifted the inline isObjectType helper to a module-scope isObjectLiteralType so both call sites share it. Adds 4 regression tests: - optional property added to inline object literal (the InstrumentationConfig case) - required property added → still rejected - property removed → still rejected - optional property added to deeply nested inline object literal Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Luca Forstner (lforst)
approved these changes
May 21, 2026
Stephen Belanger (Qard)
deleted the
fix/api-compat-optional-object-literal
branch
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
2 participants
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
areInterfaceSignaturesCompatiblewas flagging adding an optional property to an inline object literal type (e.g.mastra?: booleanonInstrumentationConfig.integrations) as a breaking change.isUnionTypeWideningwhen the strings differed. Inline object literals aren't unions, so any new field tipped it into "modified" territory.areObjectTypeDefinitionsCompatiblehelper when both sides are inline object literals, mirroring the pattern already inareTypeAliasSignaturesCompatible. Also apply the same delegation insideareObjectTypeDefinitionsCompatibleitself so nested object literals are handled the same way.isObjectTypehelper to a module-scopeisObjectLiteralTypeso the interface, object-literal, and intersection comparators share one definition.After this lands, the
js-api-compatibility (20)check on PRs that add optional integration keys (#1891, #1897, #1901, future SDK integrations) will pass instead of failing informationally.Test plan
describe("areInterfaceSignaturesCompatible", ...):InstrumentationConfigcase) → passespnpm exec vitest run tests/api-compatibility/api-compatibility.test.ts— all 14 interface-compat tests pass plus the rest of the filepnpm run fix:formattingandpnpm run lintclean#skip-changeset — this is a test-only change with no impact on the published package.
🤖 Generated with Claude Code