Open corneliu-petrescu opened 7 months ago
Ah interesting, it looks like our mergeAllOf handler doesn't handle this case.
This might be a little trickier to implement, given each oneOf child would result in a top level polymorphic item, and you could have multiple oneOf children which would result in all combinations of polymorphic options.
We have 2 or 3 APIs that use the above approach. What would be the impact of it at this moment? Is it just a warning?
I think right now it'll exclude values in oneOf
blocks that are nested inside of an allOf
block. This would affect the diff that's generated and rules run against it.
For now I'm investigating rewriting some of the schemas using
oneOf
- allOf
prop1
prop2
- allOf
prop1
prop3
This does not give any warnings
I think I just came across the same ...
optic diff reference\Configuration.yaml --last-change
Hi,
We're seeing a parse warning when trying to lint the following API spec:
Example: -- invalid allOf variant