Compiling ClientApi.ts fails due to include of unavailalble class DefaultService

[Paul Seidler]

Description

When upgrading from 0.45.1 to 0.46.3 I encountered the following compile error:

.openapi-typescript-codegen/ClientApi.ts:6:10 - error TS2305: Module '"./services.gen"' has no exported member 'DefaultService'.

6 import { DefaultService } from './services.gen';
           ~~~~~~~~~~~~~~

According to the migration docs it should be like:

import * as DefaultService from './services.gen'; 

Or do I get something wrong ?

Note: Sticking with asClass works fine.

OpenAPI specification (optional)

No response

Configuration

No response

System information (optional)

No response

[Lubos]

@sepek sounds like you figured it out? Is there anything that needs to be fixed?

[Paul Seidler]

@mrlubos thanks for the feedback!
Sorry for not being clear about my point. This file is generated by @hey-api/openapi-ts and so I consider it a bug if it produces code which results in compile errors

$ npx @hey-api/openapi-ts --input ../openapi.yaml --output ./.openapi-typescript-codegen --name ClientApi
✨ Creating Fetch client
✨ Done! Your client is located in: […]/.openapi-typescript-codegen
$ head .openapi-typescript-codegen/ClientApi.ts
import type { BaseHttpRequest } from './core/BaseHttpRequest';
import type { OpenAPIConfig } from './core/OpenAPI';
import { Interceptors } from './core/OpenAPI';
import { FetchHttpRequest } from './core/FetchHttpRequest';

import { DefaultService } from './services.gen';

type HttpRequestConstructor = new (config: OpenAPIConfig) => BaseHttpRequest;

export class ClientApi {

[Eduard Oancea]

This problem got introduced in 0.46.0

[Hallvord R. M. Steen]

I hit this on upgrading from openapi. The default behaviour (without setting a configuration option) should probably not be to generate code that does not compile..

[Anatolii Yemets]

Had to go from 0.48 to 0.45 as a temporary solution.

[Lubos]

@anatolii-yemets does it not work with services.asClass = true?

[Hallvord R. M. Steen]

@mrlubos I would respectfully suggest this bug is fixed sooner rather than later. Generating code that fails to compile gives a bad impression of an otherwise good tool. If asClass is the solution, it should be on by default and the other mode should be deprecated, to ensure users do not hit this problem.

We have a workaround, but many users will probably just give up and look for some other library if "it generates code that doesn't compile" is their first impression.

[Lubos]

@hallvors As far as I can tell, this is when using the (deprecated) name parameter? Assuming yes, it's not documented anywhere so I'd expect you to be upgrading from a prior version. And in that case, there are the migration docs. Maybe it should be clearer there? My intent is not to support name. I'm curious what use cases there are that prevent people from moving away from that setting?

[Paul Seidler]

@mrlubos first of all: Praise the migthy developers which bring us this nifty tool. Keep up the excellent work :)

Two cents for potential improvements:
For me it was not clear from the migration instructions of 0.46 that the usage should be adpoted for me it sounded more like another way to use the library which is now the default.
Also it was not clear to me that the --name paramater is not supposed to be used as it's at least documented with --help.