Skip to content

feat: add version-specific OpenAPI compilers#7

Closed
DerManoMann wants to merge 3 commits into
feat/spec-dtofrom
feat/compilers
Closed

feat: add version-specific OpenAPI compilers#7
DerManoMann wants to merge 3 commits into
feat/spec-dtofrom
feat/compilers

Conversation

@DerManoMann

Copy link
Copy Markdown
Owner

Summary

Introduces CompilerInterface and three version-specific implementations that transform a Specification into an OpenAPI document array. This is the compilation stage of the spec pipeline:

Specification → Compiler → OpenAPI document (array)

Depends on zircote#2054.

Design

Version-aware compilers

Each OpenAPI version (3.0, 3.1, 3.2) has its own compiler that handles version-specific differences rather than branching inside a single serializer.

  • OpenApi31Compiler — base implementation (JSON Schema 2020-12, full 3.1 feature set)
  • OpenApi30Compiler — extends 3.1, overrides for the draft-04 JSON Schema subset:
    • type is always a string (not array)
    • nullable as separate boolean keyword
    • exclusiveMinimum/exclusiveMaximum are booleans (alongside minimum/maximum)
    • No $ref siblings (summary/description stripped)
    • No webhooks, no const, no examples array (only singular example)
    • License: no identifier field (only url)
  • OpenApi32Compiler — extends 3.1, adds Tag summary/parent/kind and PathItem query

CompilerInterface

interface CompilerInterface
{
    public function getVersion(): string;
    public function supports(string $version): bool;
    public function compile(Specification $specification): array;
    public function validate(Specification $specification): array;
}

The compile step is a pure function (Specification in → array out), making it independently testable without the rest of the pipeline.

Compiler responsibilities (from classic processor mapping)

┌──────────────────────────────┬──────────────────────────────────────────────────────────┐
│      Classic Processor       │                   Compiler Equivalent                    │
├──────────────────────────────┼──────────────────────────────────────────────────────────┤
│ MergeIntoComponents          │ Groups schemas/parameters/responses etc. into components │
├──────────────────────────────┼──────────────────────────────────────────────────────────┤
│ BuildPaths                   │ Groups operations by resolved path                       │
├──────────────────────────────┼──────────────────────────────────────────────────────────┤
│ AugmentSchemas (allOf merge) │ Emits allOf when both properties + allOf exist           │
└──────────────────────────────┴──────────────────────────────────────────────────────────┘

Inheritance strategy

3.0 and 3.2 extend the 3.1 compiler, overriding only the methods that differ. This keeps version-specific logic minimal and co-located rather than scattered across conditionals.

DerManoMann and others added 3 commits July 12, 2026 20:29
Introduce CompilerInterface and three implementations that transform a
Specification into a versioned OpenAPI document array:

- OpenApi31Compiler — base implementation (JSON Schema 2020-12)
- OpenApi30Compiler — extends 3.1, overrides for draft-04 subset (nullable,
  exclusive min/max as booleans, no webhooks, no $ref siblings)
- OpenApi32Compiler — extends 3.1, adds Tag summary/parent/kind and PathItem query

Each compiler provides both compile() and validate() methods, keeping
version-specific logic isolated from the rest of the pipeline.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@DerManoMann

Copy link
Copy Markdown
Owner Author

Moved to zircote#2058 (base branch updated to master now that spec-dto is merged)

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.

1 participant