Closed paambaati closed 4 months ago
Can confirm that the behaviour is still broken in other ways when services.asClass
is set to true
.
Thanks! Looks like the import should be changed to wildcard? Can you describe what issues you're seeing if you set asClass to true?
@paambaati I looked into adding tree-shakeable services for custom clients, it's not a quick fix, so my suggestion would be to use services.asClass: true
to preserve the old behaviour. You said there are other issues, I can look at that once you provide more details. Generating a test client from sample script didn't produce any errors so I will need your assistance.
@mrlubos Thanks for looking at this. With services.asClass: true
, I notice 1 problem –
fetch
client.Everything else does seem to work, albeit with code changes. This is a breaking change and I was surprised this landed in a minor release.
@paambaati Can you point me to what's missing? To be clear, you're talking about the generated Fetch API client, not the new one, right?
Minor releases are actually breaking quite often if you look at the migrating docs. Until we reach v1, that's how it's going to be. Also note that --name
is deprecated and will be removed prior to v1, so I'd like to understand what's missing in order for you to migrate. However, it should've continued to work as before if you simply upgraded to v0.46.0 and set asClass to true. I'd like to fix that if you can point out the difference
@mrlubos Yes, this is using the native fetch
client.
Here's an example –
With openapi-typescript-codegen, I could have generated code like this –
const neonClient = new NeonClient({
TOKEN: '<INSERT NEON API KEY HERE>',
});
const projects = await neonClient.project.listProjects();
console.log(projects);
However, with the latest set of changes in @hey-api/openapi-ts
, this code has to be written as –
import * as NeonClient from './services.gen'
const response = await NeonClient.ProjectService.listProjects();
console.log(projects);
There's no clear way to define the token
authorization header.
@paambaati This is with asClass: true
?
This is with
asClass: true
?
@mrlubos Correct.
import { defineConfig } from '@hey-api/openapi-ts';
import { config } from './package.json';
export default defineConfig({
input: config.neonOpenApiSpec,
output: './generated/',
client: 'fetch',
services: {
asClass: true,
}
});
@paambaati I tried reproducing this and was unable to, see https://stackblitz.com/edit/hey-api-client-fetch-example-6uxsro?file=src%2FApp.tsx, both 0.45.0 and 0.46.0 appear to work the same way. Feel free to reopen if I am missing something
@mrlubos In my case, the main class (Test
in your Stackblitz example) is not being generated!
Please look at paambaati/neon-js-sdk@e709690
(#63) – I've hardcoded some example code to show that the expected NeonClient
is missing!
@paambaati there might be some confusion around the usage. 0.46.0 should not be introducing any breaking changes to your existing workflow, as long as you define asClass: true
(which you did). You still need to define name: 'NeonClient'
in your config to generate a client instance. Without it, there will be no custom class, that's why it's not generated.
The longer term recommended solution is to stop relying on the name
config option as it's deprecated. Omitting it will not generate a separate NeonClient.ts
file as you already know. Depending on how you're using this package, this may or may not matter, but you will likely need to change code in other places where you'd have previously used the client instance. For that, I think we could move this into discussions to see what needs to get updated, what (if anything) breaks, and anything else preventing you from retiring the usage of name
. Does that make sense?
tl;dr add name: 'NeonClient'
to your config and things should continue working as before
@mrlubos Thanks, using name
fixes the issue. I had recently started skipping it because the TSDoc said it was deprecated.
I will create a discussion so we can figure out a future migration path without the use of name
.
Yeah totally feel free to keep using it for now, I'm just not supporting it for new features since I know it will be going away. Same with the other deprecated parameters
Related discussion here – https://github.com/hey-api/openapi-ts/discussions/619
Description
With the latest version of the package
@hey-api/openapi-ts@0.46.0
, the generated main class is once again broken.Consider the changes in https://github.com/paambaati/neon-js-sdk/pull/63 –
0.46.0
pnpm run generate
to generate the latest client & typespnpm run build
to runtsc
and compile the outputGet this error –
OpenAPI specification (optional)
https://dfv3qgd2ykmrx.cloudfront.net/api_spec/release/v2.json
Configuration
System information (optional)
No response