Cannot create inlined enums in v0.43.x
Description
Hi, I'm facing an issue, where there are not getting any enums (js or ts) generated.
It's starting from version v0.43.0.
I did adjust the config change (enums is now a property in types), but it won't get recognized.
Workaround is to run npm install --save-dev @hey-api/[email protected] and use the old config format.
OpenAPI specification (optional)
No response
Configuration
New:
import { defineConfig } from '@hey-api/openapi-ts';
export default defineConfig({
base: '',
input: 'api.json',
output: 'src/app/core/api/__generated__',
client: 'angular',
types: {
enums: 'typescript',
},
schemas: false,
format: 'prettier',
});
Old:
import { defineConfig } from '@hey-api/openapi-ts';
export default defineConfig({
base: '',
input: 'api.json',
output: 'src/app/core/api/__generated__',
client: 'angular',
enums: 'typescript',
schemas: false,
format: 'prettier',
});
System information (optional)
❯ node --version && npm --version
v20.11.0
10.2.4
Hey @primeapple, does it happen with the Petstore spec?
I tried with this config
import { defineConfig } from '@hey-api/openapi-ts';
export default defineConfig({
base: '',
// input: 'api.json',
input: 'https://raw.githubusercontent.com/swagger-api/swagger-petstore/master/src/main/resources/openapi.yaml',
output: 'src/app/core/api/__generated__',
client: 'angular',
types: {
enums: 'typescript',
},
schemas: false,
format: 'prettier',
});
on v.0.43.2 and it still doesn't generate separate enums :(
Thanks, sounds like it might be related to Angular specifically. I'll check and fix if I can reproduce
@primeapple For completeness, what command do you use to execute openapi-ts?
Sure, I have the following in my package.json scripts section:
"generate-typescript": "openapi-ts"
And then I execute npm run generate-typescript
I think I know what's going on. Without seeing your spec, I can only guess, but my guess is it's this piece of code https://github.com/hey-api/openapi-ts/blob/main/packages/openapi-ts/src/utils/write/types.ts#L51-L54
We stopped exporting inlined enums because they created way more types, which in turn increased chances of duplicates. Additionally, these enums could be equal by value, leading to extraneous types when they're really not 2 different models.
Do you have a workaround for this issue? Do you really need to generate types for inlined enums?
So first, you can try the petstore spec: https://raw.githubusercontent.com/swagger-api/swagger-petstore/master/src/main/resources/openapi.yaml , it also doesn't create enums anymore.
And yes, I need enums. They represent the domain models I'm working with. I'll have to iterate over them, map them, etc.
The only workaround for me would be to use another library.
There surely are ways to find duplicated Enums. If they are really equal by value, I guess just keep them different, except if their name is the same, then they are probably refering to the same Enum. In this case keep only one. If this bothers the user the problem is not in this library but in his OpenAPI spec and he should choose more distinct Enum Names.
Let me look into this
@primeapple hopefully you don't mind staying on 0.42.1 for a while, this will get addressed, but unlikely this week
It's fine for me. But I wouldn't tag it as "Feature". As it worked before and is not working now, it's a regression bug but not a feature :)
Thanks for maintaining this :)
The feature part is deduplicating identical inlined enums, that's going to be new
@primeapple more enums are exported in v0.44.0, let me know if that includes what you need? I'll keep this issue open regardless because the release doesn't fully address it
That's very helpful already, I think all needed enums are there now.
What is interesting is that the casing changed in change to 0.42. There the enums where printed as PropertyKeyEnum for a property like:
"Thing": {
"type": "object",
"properties": {
"property_key": { "type": "string", "enum": ["a", "b"] }
}
}
Now the enum is simply called property_key. I guess that's fine for now, but in the future the possibility to change the casing would be awesome (maybe https://github.com/hey-api/openapi-ts/issues/558 )?
Yeah, right now it's preserving the name as defined in spec. I can have a look at casing, any particular one you're interested in?
PascalCase probably makes the most sense for now. But later we should go according to what's specified in #558
Enum deduplication added in v0.45.0, still got left to export inlined enums from operation parameters