After using the current deprecated name implementation, some desired features are:

• Keep the transient SDK, where one can invoke new individual instances of the SDK where needed. This differs from the singleton pattern which is beneficial more for Front End clients
• Replace name config option with something more meaningful, perhaps a property inside config output called sdk which can be boolean or string. if set to bool, the codegen produces the full SDK version of the code with a default name, which a string would do the same but override the SDK name.
• Compatibility with the @hey-api/client-fetch by default. The current Fetch implementation is missing some great features:
  • first-class support by hey-api
  • allow to pass request overrides per method calls, which is something awesome
• Compatibility with flat and class. The current implementation is only for class, while flat could lift all methods to the root level of the SDK

Im willing to contribute to this and help flesh these out

"Let's gauge interest before committing to this feature"

Very interested, the ability to generate an extendable SDK from openapi would be extremely useful.

const example = exampleClient()

const site = await example.getSite('uuid')

Would be amazing. I have tried openapi-generator-cli but it is a lot more difficult.

Ideally I could extend as well to add custom validation logic

await example.patchPage({id: '', html: ''})

Where I validate the HTML is correct.

👋 This is what I was using openapi-ts for originally, and loved it. A single client. I'll be pinned on 0.53.9 for now.

For context I use this as a nodejs client, so i have an app, say app-a that has a build process that also produces a typed client for app-a which i publish to npm. Then app-b can npm install app-aand doconst client = new AppA()` to interact with it.

The other thing is dependency injection & teseting, it's far easier for me to stub out a single client such as this in app-b than a whole bunch of individual functions.