fix: remove mapping restriction on polymorphic oneof types #685
Conversation
This removes the rule that fails on a defined discriminator mapping. There isn't a good reason to prevent the use of the mapping keyword in Snyk's OpenAPI specifications. I think this restriction was placed long ago, when Snyk had custom code generators that couldn't handle it. These haven't been well-maintained at Snyk though, and popular open source code generators such as oapi-codegen seem to handle it well. The language discouraging the use of discriminators also hasn't aged well. There are valid reasons and numerous use cases for union type variants in resource attributes. The Common Issue Model, assets, and findings all benefit from some conditionally-specific variant attributes.
|
The mapping objects type is a record of string to string, however the values are considered references. Since the values are not deserialised as refs by vervet, the reference objects are not copied when compiling the specs which lead to invalid specs. This is an issue with the upstream library and is hard to fix on our side. If you can resolve the above problem with vervet then this rule can be removed, it was added last month to prevent users from encountering this bug. As for polymorphic types in apis, they may have their uses but the majority of the time such types would be better modelled as seperate resources. This isn't an absolute rule which is why they are discouraged and not disallowed, there will always be some use case for it. |
|
@jgresty Thanks for the context, I was unaware of that particular problem with the refs! I'll investigate this further and get back to you. |
This removes the rule that fails on a defined discriminator mapping.
There isn't a good reason to prevent the use of the mapping keyword in Snyk's OpenAPI specifications.
I think this restriction was placed years ago, when Snyk was developing custom code generators, and these couldn't handle the complexity. These haven't been well-maintained at Snyk though, and the open source code generators we're now using, such as oapi-codegen, seem to handle these quite well.
The language discouraging the use of discriminators also hasn't aged well. There are valid reasons and numerous use cases for union type variants in resource attributes.
The Common Issue Model, assets, and findings all benefit from some conditionally-specific variant attributes.