Taming error messages #40
Conversation
philsturgeon
force-pushed
the
tame-error-messages
branch
from
4988177
to
8ddc206
Compare
philsturgeon
force-pushed
the
tame-error-messages
branch
from
8ddc206
to
1a82369
Compare
This will show a much more concise error in situations where speccy knows whats up. ``` Specification schema is invalid. /components has an unexpected additional property: properties ```
philsturgeon
force-pushed
the
tame-error-messages
branch
from
1a82369
to
96d62b9
Compare
```
expected Object {
openapi: '3.0.0',
info: Object { version: '1.0.0', title: 'Swagger 2.0 Without Scheme'
},
paths: Object {},
components: Object {
... snip ...
} to have property tags
```
philsturgeon
force-pushed
the
tame-error-messages
branch
from
96d62b9
to
ce4addf
Compare
|
Holy crap, https://github.com/torifat/better-ajv-errors looks amazing. @MikeRalphson pointed this one out, and I want it, but... it's kinda funny. These JSON Schema errors should only show up as a last resort, as "This utterly failed and we (speccy validator) do not know why."
To have this backup method be so much more fantastic looking in output seems a tad odd IMO :D I wonder if we can promote the usage of the OpenAPI v3.0.0 metadata (unofficial as it is 😅) to essentially first-pass any file it comes across, giving us this taaasty input first? What ya think folks? |
|
You just need to hoik the ajv validation out to its own function and have an option to run it first, last or never (setting whatever default you prefer). Up to you if you want to wait for openapi-kit? |
|
Replaced with #47 |
Truncate any assertion-based linter errors
This will also show a considerably more concise JSON Schema error in situations where speccy knows
whats up.