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

Missing types in client gen #36

Closed
Stono opened this issue Mar 4, 2024 · 6 comments · Fixed by #37
Closed

Missing types in client gen #36

Stono opened this issue Mar 4, 2024 · 6 comments · Fixed by #37

Comments

@Stono
Copy link
Contributor

Stono commented Mar 4, 2024

Hellooo,
Firstly, thanks for forking and implementing ferdikoomen/openapi-typescript-codegen#2044.
I'm happy to try and chip in where I can too.

I've just switched the library out for the fork, but the code generated in the client appears to be invalid.

Types of TResult, TConfig, TApiResponse are all missing in the generated files.

They seem to exist in core/types.ts, they're just not being templated into this file.

Screenshot 2024-03-04 at 10 39 38
@Stono
Copy link
Contributor Author

Stono commented Mar 4, 2024

So looking at the templating:

{{#if @root.useOptions}}
import { mergeOpenApiConfig, OpenAPI } from '../core/OpenAPI';
import { request as __request } from '../core/request';
import type { TApiResponse, TConfig, TResult } from '../core/types';
{{else}}
import { OpenAPI } from '../core/OpenAPI';
import { request as __request } from '../core/request';
{{/if}}

We're using useOptions: true.

@mrlubos
Copy link
Contributor

mrlubos commented Mar 4, 2024

@Stono oops, sorry for that. Can you share the full command you're using to generate the client? It seems you're not using exportCore, right?

@Stono
Copy link
Contributor Author

Stono commented Mar 4, 2024

Hey,
I am using exportCore.

What we're doing is a bit interesting btw, we dont use the cli - instead i invoke it programatically:

  const openApi = require('@nicolas-chaulet/openapi-typescript-codegen/dist')
  await openApi.generate({
    input: tmpLocation,
    output: destinationLib,
    httpClient: 'fetch',
    exportCore: true,
    exportServices: true,
    exportModels: true,
    exportSchemas: false,
    postfixServices: '',
    postfixModels: '',
    clientName: 'swaggerClient',
    useOptions: true,
    useUnionTypes: true
  })

Core does look to be exported as i'd expect:

Screenshot 2024-03-04 at 12 11 32

The types just aren't being imported in the generated service

@mrlubos
Copy link
Contributor

mrlubos commented Mar 4, 2024

@Stono got it, thanks! I will fix it today if you can give me one more pointer. I see this is because you use clientName, I didn't implement it with that field. Can you explain what's that field used for on your end? Do you implement anything custom?

@Stono
Copy link
Contributor Author

Stono commented Mar 4, 2024

@mrlubos just to maintain a well known name for the client, because our apps then do:

import { swaggerClient } from './swaggerClient'

It doesn't matter if it's called swaggerClient, so long as it's deterministic

@mrlubos
Copy link
Contributor

mrlubos commented Mar 5, 2024

@Stono this is fixed in v0.27.19 🚀 Thanks for catching it!

I want to ask, however, more about the use of clientName. Personally I don't use it, so it may help me prevent similar mistakes in the future. clientName will generate a file in client/swaggerClient.ts – do you use this module? If so, how? I am still not clear what you get from this flag that you couldn't get by not using it and setting output to src/swaggerClient which would then be used elsewhere as import { Services } from 'swaggerClient'?

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

Successfully merging a pull request may close this issue.

2 participants