Skip to content
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

Improve generated typenames #1591

Closed
Porges opened this issue Jun 22, 2021 · 5 comments
Closed

Improve generated typenames #1591

Porges opened this issue Jun 22, 2021 · 5 comments
Assignees
Milestone

Comments

@Porges
Copy link
Member

Porges commented Jun 22, 2021

Describe the current behavior
See: #1548 (comment)

Includes depluralization of parent type names when creating type names for subresources.

@Porges Porges added the task label Jun 22, 2021
@Porges Porges added this to the codegen-alpha-0 milestone Jun 22, 2021
@Porges Porges self-assigned this Jun 22, 2021
@Porges Porges mentioned this issue Jun 22, 2021
2 tasks
@Porges
Copy link
Member Author

Porges commented Jun 27, 2021

Marking as alpha-1 since the generated names do not affect CRDs, only the intermediate/internal go code.

Porges added a commit that referenced this issue Jul 8, 2021
1. Flattening needed to visit arrays, maps, etc to match up inner types.
2. Added a panic if we have missed flattening any properties marked `flatten: true`; improve reporting of panics during code generation process to include package/typename.
3. If types are not modified then keep using the original type. This improves the typenames a bit (#1591).
4. When matching up spec/status types to augment specs with status, ignore any optionality when matching up types. This makes things work properly with the handcrafted schemas where often the `required` attribute has been forgotten.
@theunrepentantgeek
Copy link
Member

From #1459:

Consider performing the pluralization improvements step for spec and status of resources too.
Add a golden test for pluralization?

@theunrepentantgeek
Copy link
Member

Whether we still need to do this depends on the results of #1758.

@matthchr
Copy link
Member

matthchr commented Oct 3, 2022

Still need to do this, but not critical because we don't give code-dependency guarantees right now

@theunrepentantgeek
Copy link
Member

Type names are significantly improved by #2323 so I'm closing this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

3 participants