Newly exported `DefaultService` does not exist

[paambaati]

Newly exported `DefaultService` does not exist

[paambaati]

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]

@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!

[mrlubos]

@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

[paambaati]

@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.

[paambaati]

Related discussion here – #619

[paambaati]

Can confirm that the behaviour is still broken in other ways when services.asClass is set to true.

[mrlubos]

Thanks! Looks like the import should be changed to wildcard? Can you describe what issues you're seeing if you set asClass to true?

[mrlubos]

@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.

[paambaati]

@mrlubos Thanks for looking at this. With services.asClass: true, I notice 1 problem –

1. There is no way for me to declare the API token in any of the class methods when using the 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.

[mrlubos]

@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

[paambaati]

@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.

[mrlubos]

@paambaati This is with asClass: true?

[mrlubos]

@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]

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