How to generate types in thier own files?

[IvanKalinin]

Is it possible to generate each type, enum in its own file, like in openapi-typescript-codegen instead of a single file?

[mrlubos]

Hi @IvanKalinin, not at the moment. What would be the use case?

[IvanKalinin]

That would allow me to migrate from openapi-typescript-codegen seamlessly. And overall I prefer to import like import { UserResponse } from '@mymonorepo/models/UserResponse'. Feels cleaner, and easier to maintain (e.g. on generating I immediately see what types were updated by their filenames in git status.

[mrlubos]

If I remember correctly, those files contain only the exported type, correct? So both import { UserResponse } from '@mymonorepo/models/UserResponse' and import { UserResponse } from '@mymonorepo/types.gen' convey the same meaning. Even if we supported the former and assuming exports follow the same naming pattern, the generated folder/file isn't called models anymore.

I'm also curious about the second part of your comment.

on generating I immediately see what types were updated by their filenames in git status

Are you able to describe your workflow? Also, how big is your team and how often do you need to see what changed?

[IvanKalinin]

Depends on the project. Some projects I work on consistently develop new features, deprecate some stuff, and so on. I regenerate types at least once in 3-4 weeks.
Some fields here, some there, you know. Actively developing product.

[h3adache]

I would like this feature as well, it helps us:

• minimize bundle in a monorepo.
• reduces MR sizes as apis change frequently.
• easier to navigate.
• reduce import side effects/improve loading performance.

It's interesting that openapi-typescript-codegen (which we are migrating from) supported this (and looks like maybe Orval does too?). But this was removed here in v0.31.0? Any particular reason why?

[mrlubos]

The short answer to your question is: a completely different architecture.

The answer you care about: this feature will be added back.

Question for you: how would you organise request payloads, response and error types when split into multiple files?

[h3adache]

The answer you care about: this feature will be added back.

Thank you!

Question for you: how would you organise request payloads, response and error types when split into multiple files?

For the most part, it's structured as a reusable system. There's common definitions that are stored in a separate directory/files that can be referenced across the individual services.

It's not as nice as how redocly splits out large specs but it's similarly structured.

[h3adache]

Any update on this? Is it on the roadmap somewhere? It's the only thing blocking us from migrating atm.