parameter with same name as schema conflicts

[benny-noumena]

We have a parameter and a schema with the same name but they differ in casing.

We noticed that as of 0.24, types for parameters are generated too. This results in a file override on case-insensitive file systems.

Any idea how to solve this? Is there a flag to not generate types for parameters? What about moving models and parameters in a subdirectory?

Many thanks for advice.

[markygab]

I'm seeing something similar too i think. As of 0.24 I'm getting many import errors in the client.

src/client/models/WorkflowBase.ts:5:15 - error TS2724: '"./Name"' has no exported member named 'Name'. Did you mean 'name'? import type { Name } from './Name';

Where the file Name.ts has export type name = string;

[mrlubos]

@benny-noumena @markygab can you replicate this issue in our fork? It also has a --useOperationId flag which you can set to false to generate method names based on path (worth trying?)

[benny-noumena]

@mrlubos Sadly it still is an issue :(

[mrlubos]

@benny-noumena are you able to provide spec to replicate this?

[benny-noumena]

@mrlubos You mean, like providing an openapi.yml fille? The reproduction is simple. If you have a parameter and a schema with the same name with different casing, then you end up having an export that differs only in casing. On a case-insensitive file-system this leads to the override of the file. In the end the ./models/Tenant.ts and the ./models/tenant.ts are the same file.

My solution would be to export all the parameters in a parameters namespace. But I don't know if this is feasible or not.

[mrlubos]

@benny-noumena do you then import either model or parameter in your code? Is the issue just that the generated client isn't correct?

[andrew-pledge-io]

Here's an example schema that demonstrates the problem:

openapi: 3.0.0
info:
  title: Sample API
  description: Example of conflicting component and parameter schemas
  version: 0.1.9
components:
  schemas:
    Metadata:
      type: string
  parameters:
    metadata:
      in: query
      schema:
        type: string

Generating the client and attempting to build it with TypeScript results in the following errors:

src/index.ts:10:15 - error TS2724: '"./models/Metadata"' has no exported member named 'Metadata'. Did you mean 'metadata'?

---

src/index.ts:11:31 - error TS1149: File name 'src/models/metadata.ts' differs from already included file name 'src/models/Metadata.ts' only in casing.
  The file is in the program because:
    Imported via './models/Metadata' from file 'src/index.ts'
    Imported via './models/metadata' from file 'src/index.ts'
    Matched by include pattern 'src' in 'tsconfig.json'

Additionally since I'm on a case-insensitive file system only Metadata.ts actually exists (I assume metadata.ts was overwritten).

[mrlubos]

Thank you @andrew-pledge-io. Do you import parameters anywhere in your application code? Any preference for the ideal solution?

[benny-noumena]

I don't know. We don't use these parameters for now. However I guess there was a reason why these types were added. My idea was to generate them in a separate directory parameters. Like a namespace parameters?

[mrlubos]

@benny-noumena yeah, it will be a breaking change either way which sucks. I'll try to find out the original motivation for it and go from there. I like the idea of single import module rather than having to go into subdirectories, so maybe prefix would work like we have for schemas ($), would that be okay with you?

[andrew-pledge-io]

A prefix would be a good solution for our use case.

Adding a configurable option for the prefix could make it a non-breaking change if the default is an empty prefix.

Detecting path separators in the prefix could also allow the option to be used for generating into a subdirectory? Though that perhaps is complicating things.