Incorrect class split logic for SDK when asClass: true

[imiatselski-cribl]

Description

My configuration is the following:

export default defineConfig({
  input: 'openapi.json',
  output: 'src/generated',
  plugins: [
    {
      name: '@hey-api/sdk',
      asClass: true,
      auth: false, // handle auth on client level, not function level
      instance: true,
    },
  ],
});

When I have a set of operationId's like:

v1.domain1.fn1
v1.domain2.fn2
v2.domain1.fn3
v2.domain2.fn4

it generates separate classes for v1 and v2: V1 and V2, which contain classes Domain1 and Domain2, which is expected.

The problem is that it generates a single Domain1 class for v1 and v2, which contains fn1 and fn3 methods and the same logic for domain2.

So I can call v1.domain1.fn3 and it's incorrect because v1 doesn't have fn3, it exists for v2 only.

The generated code for the specification below:

class Domain1 extends _HeyApiClient {
    public fn1<ThrowOnError extends boolean = false>(options?: Options<V1Domain1Fn1Data, ThrowOnError>) {
        return (options?.client ?? this._client).get<V1Domain1Fn1Responses, unknown, ThrowOnError>({
            url: '/v1/domain1/fn1',
            ...options
        });
    }
    
    public fn3<ThrowOnError extends boolean = false>(options?: Options<V2Domain1Fn3Data, ThrowOnError>) {
        return (options?.client ?? this._client).get<V2Domain1Fn3Responses, unknown, ThrowOnError>({
            url: '/v2/domain1/fn3',
            ...options
        });
    }
}

class Domain2 extends _HeyApiClient {
    public fn2<ThrowOnError extends boolean = false>(options?: Options<V1Domain2Fn2Data, ThrowOnError>) {
        return (options?.client ?? this._client).get<V1Domain2Fn2Responses, unknown, ThrowOnError>({
            url: '/v1/domain2/fn2',
            ...options
        });
    }
    
    public fn4<ThrowOnError extends boolean = false>(options?: Options<V2Domain2Fn4Data, ThrowOnError>) {
        return (options?.client ?? this._client).get<V2Domain2Fn4Responses, unknown, ThrowOnError>({
            url: '/v2/domain2/fn4',
            ...options
        });
    }
}

class V1 extends _HeyApiClient {
    domain1 = new Domain1({ client: this._client });
    domain2 = new Domain2({ client: this._client });
}

class V2 extends _HeyApiClient {
    domain1 = new Domain1({ client: this._client });
    domain2 = new Domain2({ client: this._client });
}

export class Sdk extends _HeyApiClient {
    v1 = new V1({ client: this._client });
    v2 = new V2({ client: this._client });
}

Reproducible example or configuration

No response

OpenAPI specification (optional)

{
  "openapi": "3.0.0",
  "paths": {
    "/v1/domain1/fn1": {
      "get": {
        "operationId": "v1.domain1.fn1",
        "responses": {
          "200": {
            "description": ""
          }
        }
      }
    },
    "/v1/domain2/fn2": {
      "get": {
        "operationId": "v1.domain2.fn2",
        "responses": {
          "200": {
            "description": ""
          }
        }
      }
    },
    "/v2/domain1/fn3": {
      "get": {
        "operationId": "v2.domain1.fn3",
        "responses": {
          "200": {
            "description": ""
          }
        }
      }
    },
    "/v2/domain2/fn4": {
      "get": {
        "operationId": "v2.domain2.fn4",
        "responses": {
          "200": {
            "description": ""
          }
        }
      }
    },
  }
}

System information (optional)

No response

[dosubot]

Hi @imiatselski-cribl! I'm Dosu and I’m helping the openapi-ts team.

The SDK codegen currently groups methods into classes based on operation tags, not the full operationId. This means if your tags (like "domain1") are reused across versions, methods from different versions end up in the same class, which causes the issue you're seeing. The documentation confirms that class names are generated from operation tags and method names from operation IDs or location, and there aren't configuration options to split classes by both version and domain when using asClass: true see docs.

If you need more granular class splitting (e.g., by both version and domain), this isn't supported out of the box. You may need to adjust your OpenAPI tags or consider a different grouping strategy until the codegen logic supports this use case.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[mrlubos]

@imiatselski-cribl is this a regression?

[mrlubos]

Again paging @flow96 🚨

[imiatselski-cribl]

@imiatselski-cribl is this a regression?

IDK, just started using the library. Tried on versions 0.80.8 and 0.80.9

[opswiz]

I think this is also related to #2435.

[flow96]

Yes, it's the same issue.
The current implementation doesn't support this kind of behaviour.

As suggested in #2435 we could adapt the implementation of the sdk plugin to use namespaces based on the root class so v1.something and v2.something would be independent of each other.

That's on you @mrlubos to decide if that's ok for you.
I could have a look on how to implement it when I find some time

[mrlubos]

@flow96 yes, I think that's how it should work. The important thing I believe is this is for instance: true, not for asClass: true which can be configured without creating an instance. Instance implementation is not fully complete, hence it's not documented yet, and issues like this exist. I'd be more cautious of changing the behavior for standalone asClass: true because lots of people depend on that.