Support library option via additionalProperties#16242
Conversation
|
I feel like this is moreso a documentation issue. Are there any particular use cases for having The recurring theme seems to be that people don't know how to figure out which options go where - or maybe some part of the documentation inadvertently implies it would go into additionalProperties. |
|
I agree improving the documentation may help. I think the confusion comes from generators documenting library as a generator option while library is actually a global option. Maybe library should be added as a generator (in java client generator) from day one as not all generators (e.g. powerhsell, crystal, lua, etc) support multiple HTTP libraries as of today. Given that this issue pops up occasionally, I think we should be able to save everyone time by converting generator option |
|
Kotlin client failure not related to this change. |
Support library option via additionalProperties as many users do it this way instead of setting library via global option.
(users who have {{library}} in their custom template need to update their template accordingly with a different tag name)
FYI @OpenAPITools/generator-core-team
PR checklist
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*.For Windows users, please run the script in Git BASH.
master(6.3.0) (minor release - breaking changes with fallbacks),7.0.x(breaking changes without fallbacks)