-
Notifications
You must be signed in to change notification settings - Fork 37
Description
Are you using OpenAPI 2, 3.0.X, or 3.1.0?
OpenAPI 3.1.0
Would this solve a problem or make something easier?
Yes, this would solve a critical compatibility issue. Modern API documentation generators like Laravel Scramble, FastAPI, and others now default to OpenAPI 3.1.0 specs. Currently, jest-openapi cannot validate these specs because it doesn't support OpenAPI 3.1.0's nullable type syntax.
Current Problem: When loading an OpenAPI 3.1.0 spec, jest-openapi throws validation errors for nullable fields:
Error: Invalid OpenAPI spec: [
{
instancePath: '/components/schemas/ArchivePageMetaDTO/properties/universe_id/type',
schemaPath: '#/properties/type/type',
keyword: 'type',
params: { type: 'string' },
message: 'must be string'
}
]
OpenAPI 3.0 vs 3.1.0 Nullable Syntax:
OpenAPI 3.0:
properties:
universe_id:
type: string
nullable: true
OpenAPI 3.1.0 (JSON Schema compliant):
properties:
universe_id:
type: ["string", "null"]
OpenAPI 3.1.0 removed the nullable keyword in favor of JSON Schema's native null type support.
What would you like to happen?
jest-openapi should support OpenAPI 3.1.0 specifications, including:
Accept type as an array of types (e.g., ["string", "null"])
Properly validate nullable fields using the JSON Schema-compliant syntax
Maintain backward compatibility with OpenAPI 3.0.X specs
Example test that should work:
import jestOpenAPI from 'jest-openapi';
// Load OpenAPI 3.1.0 spec
jestOpenAPI('./swagger.json'); // Contains openapi: "3.1.0"
// This should pass validation
expect(response).toSatisfyApiSpec();
Describe alternatives you've considered
Convert OpenAPI 3.1.0 to 3.0 format - Requires additional build step, loses 3.1 features, and is not sustainable as tools move to 3.1.0
Disable OpenAPI validation entirely - Defeats the purpose of contract testing
Manual response validation - Error-prone and doesn't leverage the OpenAPI spec
Use different testing library - No viable Vitest-compatible alternatives exist that support OpenAPI 3.1.0
None of these alternatives are ideal. Supporting OpenAPI 3.1.0 natively would be the proper solution.
Additional context or screenshots
Environment:
jest-openapi version: 0.14.2
Node version: 20.x
OpenAPI spec generator: Laravel Scramble
OpenAPI spec version: 3.1.0
Example OpenAPI 3.1.0 Schema (Generated by Laravel Scramble):
{
"openapi": "3.1.0",
"components": {
"schemas": {
"ArchivePageMetaDTO": {
"properties": {
"universe_id": {
"type": ["string", "null"]
},
"product": {
"type": ["string", "null"]
}
}
}
}
}
}
Tools that generate OpenAPI 3.1.0 by default:
Laravel Scramble (no option to use 3.0)
FastAPI
OpenAPI Generator (has 3.1 support)
Swagger UI (supports 3.1 since v4.0)
References:
OpenAPI 3.1.0 Specification
Migrating from OpenAPI 3.0 to 3.1.0
OpenAPI 3.1 and JSON Schema 2020-12
Are you going to resolve the issue?
I'm open to contributing if guidance is provided on:
Which OpenAPI parser/validator library to migrate to (or upgrade)
Whether this should be a major version bump
If backward compatibility with 3.0 should be maintained
Testing approach for ensuring both 3.0 and 3.1 specs work
However, I'm not deeply familiar with this codebase yet, so maintainer input would be valuable before I start working on a PR.