Ability to process multiple input files

[rakeshpai]

Would it be possible to add support for multiple OpenAPI spec files? If such a support exists, could you please point me to how I can use it?

In my code, we need to talk to multiple services, and each have their own OpenAPI spec files, a copy of which we have in our repo. However, when I run openapi-typescript-codegen, since I can only give it one input file, the generated code is only oriented towards one service. However, it should be possible to reuse a lot of the stuff defined in the generated/core directory, and we only need to create multiple service clients in the generated/services/ directory, and export them all in the generated/index.ts file. Shipping multiple clients for each service is not ideal, since we're working on a front-end client, so need to minimise the code we ship to end users.

I could maybe build a slightly ugly workaround, where I run openapi-typescript-codegen for each spec file, and then move some files and edit others, but it would be ideal if support for this was built in.

[mrlubos]

How would you handle conflicting service or model names?

[rakeshpai]

I'm new to this repo, so all I have is newb suggestions.

Couldn't we just take in the service name as an argument either as CLI args or as a parameter in the programmatic API? I'm thinking something like:

const OpenAPI = require('https://github.com/ferdikoomen/openapi-typescript-codegen');

OpenAPI.generate({
    inputs: [
      { file: './spec1.ts', name: 'AuthService' },
      { file: './spec2.ts', name: 'PermissionsService' }
    ],
    output: './generated',
});

Realistically though, it's unlikely for service names to clash in a project. If it does, it might even be ok to throw an error.

I'm not sure about handling model names - when I ran codegen, my models folder was empty, so I don't have an opinion about it. But if the models are somehow scoped to the service, it shouldn't matter if their names clash with that of another service.

[mrlubos]

Services are also generated from OpenAPI tags, so if the projects contain the same tag, there would be clashes. As for the empty models folder, did you run the generator with the exportModels flag enabled?

For your original request, what do you think about a generated folder structure like this?

src
└── client
    ├── core
    ├── project-one
    │   ├── models
    │   ├── schemas
    │   ├── services
    │   └── index.ts
    ├── project-two
    │   ├── models
    │   ├── schemas
    │   ├── services
    │   └── index.ts
    └── index.ts

Models, schemas, and services would be nested inside their project folders and exported through index.ts, so no clashes would occur. I think your ask is about shared core, which would be achieved with this approach. You'd then import services as import { MyService } from 'client/project-one' instead of import { MyService } from 'client' which is the approach today.

One question, do all your services work with the same authorization token?

[rakeshpai]

Yup, your suggestion looks good to me. You're right, my ask is that the core can be shared.

I'm only newly getting onboarded to the project I'm working on, so I don't know too much about how the auth works. My current understanding is that it's the same token being used across services, but I could be wrong. Would that be something to handle as well when considering multiple spec inputs?

[mrlubos]

Definitely – you'd need a mechanism to tell the shared core which token to use for which project. I think the easiest way for you is to build a separate client for each project. If your services can be connected seamlessly, you might get a better mileage out of modifying the generated files to do what you describe above (shared core, combined services, etc)