Support for pluggable filters in the resolver about oas-kit HOT 8 CLOSED

Example of a filter, the JSON Schema to OpenAPI conversion layer that goes into each of the different protocol things. wework/speccy#45

from oas-kit.

Cool. Will probably be implemented as an array of callbacks which can mutate the content. Do you think anyone is ever going to want to massage the text before it gets parsed by js-yaml ?

from oas-kit.

I can only guess, but for me no.

from oas-kit.

Good, simpler the better.

from oas-kit.

options.filters is now an (optional) array of functions which take two parameters, data and options and must return the filtered data.

oas-kit should be a step towards re-integrating speccy with the new oas-resolver package and possibly oas-validator in the future (you would provide your own linter presumably which would be plugged in instead of oas-linter).

from oas-kit.

Sweet! Is this ready for me to rewrite speccy around or what's the deal?

from oas-kit.

I think the refactoring of swagger2openapi into oas-kit as a mono-repo is now stable. I don't believe you made any other changes to the resolver apart from the ability to plug in your JSON-Schema dialect converter? If that's the case, then switching over to using oas-resolver as a dependency should be pretty trivial.

It will take a little longer for me to work out whether the validator changes can be sync'd up again, and if so what changes if any are needed to the interface between the validator and the linter.

I'm happy to do anything to reduce the code duplication between the projects, but I know you were at least toying with the idea of using ajv (with better-ajv-errors) as the primary validator. oas-validator now has an option to do ajv first, last or never, but ajv-errors-are-still-pretty-shit :)

from oas-kit.

Work being done in wework/speccy#98

from oas-kit.