Coming from openapi-typescript-codegen, it's sad to see that generating seperate files per type is no longer possible since v0.31.0. I've seen issue #357 and read the arguments against this approach, but I also believe it offers some advantages over a single file from a dev ex point of view:
My types.gen.ts is currently over 12 000 lines. I wouldn't call that easy to navigate. When inspecting a single type I find seeing 3/4/5 other types very distracting, especially when you put another file on that tab and come back to the types file later.
With seperate files you're able to e.g. crtl + shift + p (in VS code) to jump to a type definition regardless of your current open files. That's faster then opening types.gen.ts first and searching from there. If you don't want these single files to clutter the file search, VS Code has options to exclude certain folders. This can be shared with your team since they're workspace settings.
In git, you can see which types changed by just looking at which files changed. In the current implementation you need to inspect the changes inside types.gen.ts in order to find out which is slower.
Having seperate files per type can also be required by a style guideline defined by the company you work for.
As mentioned in the other ticket, it's a question of preference. Both approached offer advantages and disadvantages and it often boils down to the specific project you're working on. Reintroducing seperate files as an option would be a killer feature. They could even be reexported from the existing files to minimize friction when deciding the best approach for your current project.
It might look something like this:
export default defineConfig({
output: {
// Set in output for preferred global behavior.
// Current behavior "merged" can remain default.
files: 'merged' | 'seperate'
},
types: {
// Ability to set specifically for types, services, ...
files: "merged" | "seperate"
},
})
Description
Coming from
openapi-typescript-codegen
, it's sad to see that generating seperate files per type is no longer possible sincev0.31.0
. I've seen issue #357 and read the arguments against this approach, but I also believe it offers some advantages over a single file from a dev ex point of view:types.gen.ts
is currently over 12 000 lines. I wouldn't call that easy to navigate. When inspecting a single type I find seeing 3/4/5 other types very distracting, especially when you put another file on that tab and come back to the types file later.crtl
+shift
+p
(in VS code) to jump to a type definition regardless of your current open files. That's faster then openingtypes.gen.ts
first and searching from there. If you don't want these single files to clutter the file search, VS Code has options to exclude certain folders. This can be shared with your team since they're workspace settings.types.gen.ts
in order to find out which is slower.As mentioned in the other ticket, it's a question of preference. Both approached offer advantages and disadvantages and it often boils down to the specific project you're working on. Reintroducing seperate files as an option would be a killer feature. They could even be reexported from the existing files to minimize friction when deciding the best approach for your current project.
It might look something like this: