Skip to content

feat(json-schema-document): infer no type from OpenAPI number formats - #11123

Draft
robert-hebel-sb wants to merge 1 commit into
feat/json-schema-2020-12-recursive-keywordsfrom
feat/json-schema-2020-12-number-formats
Draft

robert-hebel-sb wants to merge 1 commit into
feat/json-schema-2020-12-recursive-keywordsfrom
feat/json-schema-2020-12-number-formats

Conversation

@robert-hebel-sb

@robert-hebel-sb robert-hebel-sb commented Oct 28, 2026 •

Copy link
Copy Markdown
Contributor

Description

In a standalone document, the formats int32, int64, float and double no longer imply integer/number for a schema without type. The json-schema-document renderer instance gets its own getType; the shared one is untouched, so OpenAPI 3.1/3.2 behavior is unchanged.

Part 4 of 5 of a stack on top of #11117 (standalone JSON Schema 2020-12).

Motivation and Context

These formats are defined by OpenAPI, not by JSON Schema 2020-12, so { "format": "int32" } was shown as integer although any type is valid.

How Has This Been Tested?

  • Unit tests (npm run test:unit -- test/unit/core/plugins/json-schema-document) and ESLint on the plugin and its tests passed locally on this branch, while the local swagger-client tarballs were still in place.
  • A Playwright spec for the feature is included; it was not run.
  • Not re-run against the released swagger-client (the tarballs are dropped in feat(json-schema-document): render standalone JSON Schema 2020-12 #11117); CI is expected to fail until the release this stack depends on is published.

Screenshots (if appropriate):

Checklist

My PR contains...

  • No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
  • Dependency changes (any modification to dependencies in package.json)
  • Bug fixes (non-breaking change which fixes an issue)
  • Improvements (misc. changes to existing features)
  • Features (non-breaking change which adds functionality)

My changes...

  • are breaking changes to a public API (config options, System API, major UI change, etc).
  • are breaking changes to a private API (Redux, component props, utility functions, etc.).
  • are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
  • are not breaking changes.

Documentation

  • My changes do not require a change to the project documentation.
  • My changes require a change to the project documentation.
  • If yes to above: I have updated the documentation accordingly.

Automated tests

  • My changes can not or do not need to be tested.
  • My changes can and should be tested by unit and/or integration tests.
  • If yes to above: I have added tests to cover my changes.
  • If yes to above: I have taken care to cover edge cases in my tests.
  • All new and existing tests passed.

@robert-hebel-sb
robert-hebel-sb force-pushed the feat/json-schema-2020-12-number-formats branch 2 times, most recently from 50c0732 to fb28ecc Compare October 28, 2026 12:38
For a schema without "type", the json-schema-2020-12 renderer infers
integer from the formats int32 and int64, and number from float and
double. OpenAPI defines these formats; JSON Schema 2020-12 doesn't, so
in a standalone document { "format": "int32" } was shown as integer
although any type is valid.

JSONSchemaDocument's renderer instance now takes its own getType, a copy
of the json-schema-2020-12 one (kept in step by a unit test) in which
those four formats imply no type: neither integer/number nor the string
that any other format implies. An explicit type and the other
inferences are unchanged. The shared getType is untouched, so OpenAPI
3.1/3.2 Schema Objects still show integer and number.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@robert-hebel-sb
robert-hebel-sb force-pushed the feat/json-schema-2020-12-number-formats branch from fb28ecc to fca6d49 Compare October 29, 2026 11:12
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.

2 participants