Skip to content

exploration: Add capability-aware API schema versioning#13

Draft
wouter173 wants to merge 2 commits into
mainfrom
feat/issue-12-api-versioning
Draft

exploration: Add capability-aware API schema versioning#13
wouter173 wants to merge 2 commits into
mainfrom
feat/issue-12-api-versioning

Conversation

@wouter173

Copy link
Copy Markdown
Owner

Summary

  • add custom Effect Schema availability annotations for Matrix spec versions and MSCs
  • build runtime schemas whose fields match literal homeserver capabilities and inferred TypeScript types
  • support MSC-to-stable promotion, version validation, docs, and focused tests

Verification

  • package TypeScript typecheck
  • 76 tests across 10 files
  • formatting and baseline lint checks

Closes #12

type SelectFields<Fields extends Schema.Struct.Fields, Capabilities extends MatrixCapabilities> = {
readonly [Key in keyof Fields as Fields[Key] extends VersionedField<Schema.Top, infer Availability>
? IsAvailable<Capabilities, Availability> extends true
? Key

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

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

[P1] Keep widened capabilities aligned with runtime

This key remapping treats every non-literal availability result as unsupported because a boolean result does not extend true. For example, with const caps: MatrixCapabilities = { version: matrixVersion(1, 2) }, a field gated since v1.1 is present in schema.fields at runtime, but typeof schema.Type contains only the ungated fields. The same mismatch affects MSC arrays stored as ReadonlyArray<Msc>. This is especially likely for capabilities discovered at startup, and contradicts the documentation claim that literals merely give the most precise type. Please either model unknown gates conservatively (for example as optional/union fields) or reject widened capabilities at the API boundary, and add type/runtime tests for a value typed as MatrixCapabilities.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

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

Fixed in c92395f. Availability is now modeled as true, false, or uncertain: literal capabilities retain exact required/omitted struct fields, while widened versions or MSC arrays expose undecidable gated fields as optional and keep the runtime fields map typed as a partial map of the original schemas. I also corrected widened ReadonlyArray handling so it no longer implies definite support for every MSC. The new regressions cover both widened MatrixCapabilities and widened MSC arrays at the type and runtime levels; package typecheck, focused tests (7/7), and the full package suite (78/78) pass.

@wouter173 wouter173 left a comment

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

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

Review summary: the literal-capability path, stable/MSC OR semantics, runtime annotation lookup, exports, docs, and focused tests look good. Package typecheck and the 5 versioning tests pass. I found one blocker in the widened-capability path: the inferred schema type can omit fields that the runtime schema contains, so values discovered or stored as MatrixCapabilities are not type/runtime aligned. Details and a suggested direction are in the inline comment.

@wouter173
wouter173 marked this pull request as draft July 17, 2026 09:00
@wouter173 wouter173 changed the title Add capability-aware API schema versioning feat: Add capability-aware API schema versioning Jul 17, 2026
@wouter173 wouter173 changed the title feat: Add capability-aware API schema versioning [insipration] feat: Add capability-aware API schema versioning Jul 17, 2026
@wouter173 wouter173 changed the title [insipration] feat: Add capability-aware API schema versioning exploration: Add capability-aware API schema versioning Jul 17, 2026
@wouter173 wouter173 added the exploration AI made pr and implementation prompted with limited knowledge to explore possible implementations label Jul 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

exploration AI made pr and implementation prompted with limited knowledge to explore possible implementations

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Api versioning

1 participant