-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add isEnumRef, isEnumOrRef to CodegenProperty #13880
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, and I think it's a good solution that doesn't break all the generators 👍
Consider finding all isEnum and replace with something like isEnum_Deprecated then properly fix isEnum. This would make it obvious to mustache authors there is something wrong with the enum property they are using. |
@devhl-labs to be clear, |
I'm not suggesting you deprecate isEnum.
This says that the current implementation is bugged, so deprecate that bugged version. Then make 'new' isEnum (which can still be called isEnum since the bugged version was renamed) which is fixed. Also, there is isInnerEnum which is true for inline enums. The benefit here is that templates using the bugged version will be very obvious, plus isEnum can be true for all enums as you would expect. |
From a software engineering perspective I agree with @devhl-labs. Do it right, now, or you'll be stuck with some decision that might not be best for the codebase, will result in confusion among contributors, will result in tech debt, and doesn't really solve the underlying issue. From a consumer perspective. I don't care which as long as it gets fixed 😂 |
Thanks for all the feedback. We definitely want to fix the issue and there were already several attempts (PRs) from the community before to fix it but no one has the time to fix all the generators (at least 10+) impacted by the fix. We can leave this PR opened and ask the community to fix the generator one by one but this will result in a lot of overhead (e.g. rebase) and it will become a giant PR that is hard to review and work on so I would rather update the default codegen with |
I dont understand your concern. The current bugged isEnum can remain in the
code exactly as it is today in master, just under a different name. That
can be done with a search and replace to change the name. Then add back
isEnum that works correctly.
The proposed solution here leaves isEnum in a bugged state (and not obvious
that it is bugged) and adds seemingly unecessary enum properties. isEnum
and isInnerEnum should be all that is needed (plus isEnum_Deprecated for
the current bugged implementation of isEnum).
But I've made my point so I'll leave you to it here.
…On Mon, Nov 7, 2022, 21:59 William Cheng ***@***.***> wrote:
Thanks for all the feedback.
We definitely want to fix the issue and there were already several
attempts (PRs) from the community before to fix it but no one has the time
to fix all the generators (at least 10+) impacted by the fix.
We can leave this PR opened and ask the community to fix the generator one
by one but this will result in a lot of overhead (e.g. rebase) and it will
become a giant PR that is hard to review and work on so I would rather
update the default codegen with isEnumRef, isEnumOrRef and let the
community of each generator to update the templates accordingly.
—
Reply to this email directly, view it on GitHub
<#13880 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHCFMKM2IFZK3FBQESNJTQLWHG6XZANCNFSM6AAAAAARUTIMWQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I agree with @devhl-labs, isEnum is the bugged one and should be fixed. Replacing the current isEnum with isEnum_Deprecated and fixing the actual bug is the right approach to me. |
To address the bug that
isEnum
is not set properly when the enum is a reference (instead of an inline schema) in a codegen property, I've addedisEnumRef
and alsoisEnumOrRef
mustache tags to provide a migration path to address the issue.Why not simply just fix it like #9526? We appreciate the fix but the problem is that it impacts lots of generators and some output won't even compile/work any more: https://gist.github.com/wing328/d8ef17e0b884ea821f2c7a1218ab368f
isEnumRef
is set to true if the it's a $ref and the $ref is an enum.isEnumOrRef
is set to true ifisEnumRef
orisEnum
is set to trueI've updated
r
templates to useisEnumOrRef
and there's no change in the output.I've updated
powershell
templates to useisEnumOrRef
, which results in a fix.Some tests in this PR comes from #13389 (credit @rivancic)
After this PR is merged, users can update the template and/or generator accordingly to ensure the output works using
isEnumOrRef
orisEnumRef
and of course we welcome PRs to apply these fix upstream in this official repo.Related PRs/issues:
cc @aymanbagabas @questionableque @snowe2010 @oszust002 @rivancic @flowstef @LukeMarlin
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.1.0) (minor release - breaking changes with fallbacks),7.0.x
(breaking changes without fallbacks)cc @OpenAPITools/generator-core-team