Open someone1 opened 5 years ago
Related to https://github.com/OpenAPITools/openapi-generator/pull/1360 though my spec is v2 not v3, looks like the code is shared between the two anyway. It appears the PR is still missing support for allOf
compositions.
Also, this issue is in reference to the 4.0.x branch so I think this is a dupe of many other issues that reference the 3.x version of the tool, but not the 4.0.x version. Feel free to close if you think existing issues/PRs are sufficient.
Pinging for ideas here - this is still an issue with the latest nightly
@someone1 did you solve this? I'm hitting this bug now. I think the bug is when using allOf
in inline response. If I defined the response in definitions
, the generated model is correct.
Version: 4.3.0 OS: macOS Catalina
I have a script to generate the output, make some changes to the package.json
(e.g. using esnext
) and run this oneliner - though to be fair it's been some months since I last had to run this as I've mostly shifted to a new project and opted to use gRPC + OpenAPI extensions instead:
find ./src/models -type f -exec sed -i -e 's/!exists.\+PagingFromJSON.\+,/PagingFromJSON(json),/g' {} \; \
One solution may be to add type: object definition to the Paging component Paging is an any type schema with an (object) properties constraint which is probably not generally supported by our tooling
Description
The generated deserializer for unioned types incorrectly inlines the unioned types
openapi-generator version
openapi-generator-cli-4.0.0-20181126.024631-44
OpenAPI declaration file content or url
Generated Code (excerpt):
Example response (notice no
"Paging"
key):Command line used for generation
openapi-generator generate -i openapi.yaml -l typescript-fetch -c es6.json -o ./typescript-api/
Steps to reproduce
Related issues/PRs
PR #569
Suggest a fix/enhancement
Not sure - the debugModels output makes it look like the generated code is accurate, there is something automatically creating a nested key for the composed model which should have its properties extend the model as it is not named.
Any ideas on how to tackle this? It almost appears as if the models passed to the template is incorrect (adding a named var
Paging
instead of its properties).cc @Place1