The CLI currently outputs human-readable error messages, which works well for interactive use but is harder to parse in CI/CD pipelines or editor integrations.
Issue #160 ("No specific error information available", open since 2022) highlights how vague error messages make debugging difficult. A structured JSON output mode would solve this by emitting parseable error objects with:
path: the location in the spec where the error occurredmessage: human-readable descriptionrule: the specification rule that was violated (e.g. openapi.3.1.schema-validation)severity: error / warning / infosuggestion: (optional) guidance on how to fix
This could be activated via --format json or controlled through the Python API by passing a structured formatter. Existing validators like spectral (--format json) and vacuum already support this pattern.
The openapi-core ecosystem would also benefit — consumers like prism or openapi-core could consume structured validation results without string-parsing output.
The CLI currently outputs human-readable error messages, which works well for interactive use but is harder to parse in CI/CD pipelines or editor integrations.
Issue #160 ("No specific error information available", open since 2022) highlights how vague error messages make debugging difficult. A structured JSON output mode would solve this by emitting parseable error objects with:
path: the location in the spec where the error occurredmessage: human-readable descriptionrule: the specification rule that was violated (e.g.openapi.3.1.schema-validation)severity: error / warning / infosuggestion: (optional) guidance on how to fixThis could be activated via
--format jsonor controlled through the Python API by passing a structured formatter. Existing validators like spectral (--format json) and vacuum already support this pattern.The openapi-core ecosystem would also benefit — consumers like prism or openapi-core could consume structured validation results without string-parsing output.