How to migrate to the new plugins system?

[Holt59]

I'm trying to migrate my code to latest openapi-ts but I cannot find any information to migrate to the new plugin systems... I've updated my config to look like this:

import { defineConfig } from '@hey-api/openapi-ts';

export default defineConfig({
  input: 'http://127.0.0.1:8000/openapi.json',
  output: 'src/client',
  plugins: [
    { name: '@hey-api/client-axios', throwOnError: true },
    {
      name: '@hey-api/sdk',
      asClass: true,
    },
    {
      name: '@hey-api/typescript',
      enums: 'javascript',
    },
  ],
  base: '/api/v1',
});

But most service calls have changed, in particular:

• requestBody seems to have been renamed body everywhere?
• the return value of the service call is now an AxiosResponse<XXX> instead of simply XXX?

Is there a proper migration guide somewhere (https://heyapi.dev/openapi-ts/migrating does not contain anything I could find)? Is there a way to get the old behavior, i.e., not get an AxiosResponse but directly the underlying type?

[mrlubos]

Which version are you migrating from?

[mrlubos]

As for your questions, yes it's body now. I am not entirely clear on the question around response. We do return response which is whatever Axios returns https://github.com/hey-api/openapi-ts/blob/main/packages/client-axios/src/client.ts#L60, but if you want only data that's accessible through data

[Holt59]

Yes that's my point, I'm not sure I understand why this was changed? Is there a way to not get the response and directly have data as it was before?

[mrlubos]

It's not possible right now. I suppose one could write their own client and patch it that way, or we could add some option to narrow down the result to a single field. Both would accomplish that, neither approach has been prioritised because only a small portion of openapi-typescript-codegen users migrated.

As to why... one of our design goals is to avoid introducing patterns that would lock users into bad decisions by default. This is one such example. Keeping data as the default result would cause the same pain you're experiencing now to anyone wanting to access more than just data.

Unless you're looking for a specific feature, I wouldn't recommend migrating. Once we get to v1, I'd feel comfortable telling you it's a good use of your time!

[Holt59]

Honestly, looking at how migrating has been up to now, it feels like waiting for v1 would mean changing 99% of my codebase using openapi-ts, I'd rather do it little by little.

As to why... one of our design goals is to avoid introducing patterns that would lock users into bad decisions by default. This is one such example. Keeping data as the default result would cause the same pain you're experiencing now to anyone wanting to access more than just data.

For me the whole purpose of using something like openapi-ts (or the original codegen) is exactly to not have to deal with anything other than data. Errors are handled through proper exceptions (not return code), and if I ever need to access something, then in that case I could have an option to handle it.

[mrlubos]

Yes, but there was no way in openapi-typescript-codegen to access response headers/status.

The main reason I don't urge you to migrate is because I plan to add more customisation options around the generated output. And if you happen to find them useful, it would mean rewriting stuff again, so why not save yourself time as it doesn't seem you need to migrate now