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

Create a test and example using enums. #110

Open
seriouslag opened this issue May 3, 2024 · 4 comments
Open

Create a test and example using enums. #110

seriouslag opened this issue May 3, 2024 · 4 comments
Labels
documentation Improvements or additions to documentation enhancement New feature or request help wanted Extra attention is needed

Comments

@seriouslag
Copy link
Collaborator

Is your feature request related to a problem? Please describe.
There are consumers of this library that use enums, we have no tests or examples showing their generation/usage.

Describe the solution you'd like
A unit test or snapshot showing their creation.

Describe alternatives you've considered
None,

@seriouslag seriouslag added documentation Improvements or additions to documentation enhancement New feature or request help wanted Extra attention is needed labels May 3, 2024
@sschuberth
Copy link

sschuberth commented May 12, 2024

I also struggle to get back the behavior from version 0.5.3 which e.g. generated

export namespace CreateRepository {

    export enum type {
        GIT = 'GIT',
        GIT_REPO = 'GIT_REPO',
        MERCURIAL = 'MERCURIAL',
        SUBVERSION = 'SUBVERSION',
        CVS = 'CVS',
    }


}

instead of version 1.3.0 now generating

export type CreateRepository = {
    type: 'GIT' | 'GIT_REPO' | 'MERCURIAL' | 'SUBVERSION' | 'CVS';
    url: string;
};

Using --enums typescript does not seems to have any effect.

Edit: Here's an excerpt from the used API spec:

      "CreateRepository" : {
        "required" : [ "type", "url" ],
        "type" : "object",
        "properties" : {
          "type" : {
            "type" : "string",
            "enum" : [ "GIT", "GIT_REPO", "MERCURIAL", "SUBVERSION", "CVS" ]
          },
          "url" : {
            "type" : "string"
          }
        }
      },

@sschuberth
Copy link

Using --enums typescript does not seems to have any effect.

Maybe this could be related to hey-api/openapi-ts#547?

@seriouslag
Copy link
Collaborator Author

Using --enums typescript does not seems to have any effect.

Maybe this could be related to hey-api/openapi-ts#547?

That does seem related.
When they patch @hey-api/openapi-ts, we will need to write some tests to determine whether it is safe to update in the future.

There are lots of moving parts.
We would appreciate the help if you have time to write tests that satisfy your use case.

Maybe fallback to an old version of this library until the new release of @hey-api/openapi-ts

@primeapple
Copy link

The new version 0.44.0 of openapi-ts fixes this problem and generates enums again.

Etsija added a commit to doubleopen-project/ort-server that referenced this issue May 16, 2024
The changed query client lead to some fixes needed in the UI code to
adapt to changes, which are listed here for further reference:

- to access the "message" and "cause" fields of the ApiError body in the
  error toast component, intermediate type casting of error.body to
  "any" was needed. NOTE: it should be investigated, why this has
  changed, as before we had direct access to error.body.message and
  error.body.cause in the UI

- earlier on, the service functions like
  ProductsService.getProductById() were called with passing parameters
  directly, but now the parameters need to be passed as objects

- The openapi-react-query-codegen uses openapi-ts as an underlying
  engine for code generation, and inline enums were broken in the latter
  [2]. While this has already been fixed in openapi-ts, the fix has not
  yet been taken into use in openapi-react-query-codegen [1]. Until the
  openapi-react-query-codegen is updated, the inline enums need to be
  accessed differently, as in

    z.nativeEnum(CreateRepository.type) needs to be changed into
    z.enum($CreateRepository.properties.type.enum)

  Note that when the library is updated, this change probably needs to
  be reverted back to its original form.

[1]: 7nohe/openapi-react-query-codegen#110
[2]: hey-api/openapi-ts#547

Signed-off-by: Jyrki Keisala <jyrki.keisala@doubleopen.org>
github-merge-queue bot pushed a commit to eclipse-apoapsis/ort-server that referenced this issue May 16, 2024
The changed query client lead to some fixes needed in the UI code to
adapt to changes, which are listed here for further reference:

- to access the "message" and "cause" fields of the ApiError body in the
  error toast component, intermediate type casting of error.body to
  "any" was needed. NOTE: it should be investigated, why this has
  changed, as before we had direct access to error.body.message and
  error.body.cause in the UI

- earlier on, the service functions like
  ProductsService.getProductById() were called with passing parameters
  directly, but now the parameters need to be passed as objects

- The openapi-react-query-codegen uses openapi-ts as an underlying
  engine for code generation, and inline enums were broken in the latter
  [2]. While this has already been fixed in openapi-ts, the fix has not
  yet been taken into use in openapi-react-query-codegen [1]. Until the
  openapi-react-query-codegen is updated, the inline enums need to be
  accessed differently, as in

    z.nativeEnum(CreateRepository.type) needs to be changed into
    z.enum($CreateRepository.properties.type.enum)

  Note that when the library is updated, this change probably needs to
  be reverted back to its original form.

[1]: 7nohe/openapi-react-query-codegen#110
[2]: hey-api/openapi-ts#547

Signed-off-by: Jyrki Keisala <jyrki.keisala@doubleopen.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants