Skip to content

[fix][elixir] wrong typespec generation for all-of with single ref #21139

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

Conversation

efcasado
Copy link
Contributor

@efcasado efcasado commented Apr 24, 2025

Description

This PR addresses the issue reported in #21135 - ie. an issue with the generated typespecs that would prevent some generated clients from compiling; but it also introduces the following changes:

  • Remove dead code
  • More idiomatic type mappings and language-specific types
  • Refactor type detection and typespecs generation to improve code re-usability and mantainability

All in all, this should contribute to make the Elixir generator easier to extend and more maintainable.

As usual, curious to hear your thoughts @mrmstn, @wing328 🙂

PR checklist

  • Read the contribution guidelines.
  • Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
  • Run the following to build the project and update samples:
    ./mvnw clean package || exit
    ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
    ./bin/utils/export_docs_generators.sh || exit
    
    (For Windows users, please run the script in Git BASH)
    Commit all changed files.
    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*.
    IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
  • File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
  • If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@efcasado efcasado force-pushed the fix-typespec-unconventional-primitive-types branch 2 times, most recently from 2ef197c to b4f9a26 Compare April 24, 2025 16:17
@efcasado efcasado force-pushed the fix-typespec-unconventional-primitive-types branch from b4f9a26 to 23e74d7 Compare April 24, 2025 16:40
@efcasado efcasado marked this pull request as ready for review April 24, 2025 17:11
typeMapping.put("UUID", "String");
typeMapping.put("URI", "String");
// primitive types
typeMapping.put("string", "String.t");
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now, we are truly mapping to Elixir built-in types.

"PID",
// This is a workaround, since the DefaultCodeGen uses our elixir TypeSpec
// datetype to evaluate the primitive
"integer()",
Copy link
Contributor Author

@efcasado efcasado Apr 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is more idiomatic and allows us to better identify what schemas may need a custom model doing something along the lines of languageSpecificPrimitives.contains(type)

} else if (!StringUtils.isEmpty(p.get$ref())) {
switch (super.getTypeDeclaration(p)) {
case "String":
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With better type mappings, code like this one (which was incomplete and should have also included other types such as Map, etc.) is no longer necessary.

@@ -784,24 +762,6 @@ public ExtendedCodegenOperation(CodegenOperation o) {
this.operationIdCamelCase = o.operationIdCamelCase;
}

private void translateBaseType(StringBuilder returnEntry, String baseType) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method wasn't used anywhere in the generator.

@@ -180,14 +234,14 @@ defmodule OpenapiPetstore.Api.Fake do

- `connection` (OpenapiPetstore.Connection): Connection to server
- `opts` (keyword): Optional parameters
- `:body` (float()): Input number as post body
- `:body` (number()): Input number as post body
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

number() is more accurate since we are not specifying any format in the OAS. number() captures whole numbers and floating point numbers (see here).

@efcasado
Copy link
Contributor Author

efcasado commented Apr 24, 2025

I think this is quite a milestone 😄

==> cloudflare
Compiling 5606 files (.ex)
Generated cloudflare app

Now, we can use the Elixir generation to build non-trivial clients (yeah, 5,606 files including model and API files). The above is the output I got when running this version on Cloudflare's official OAS (see here). This wasn't possible a few weeks ago 😄

@efcasado efcasado changed the title fix: wrong typespec generation for all-of with single ref [fix][elixir] wrong typespec generation for all-of with single ref Apr 24, 2025
@wing328
Copy link
Member

wing328 commented Apr 25, 2025

nice, we will try to get it merged before the v7.13.0 release due this week

@wing328 wing328 added this to the 7.13.0 milestone Apr 25, 2025
@wing328 wing328 merged commit 0462bed into OpenAPITools:master Apr 25, 2025
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants