fix(enum-values): access optional prop child props #2139
Conversation
❌ Deploy Preview for openapi-ts failed.
|
|
darkbasic
force-pushed
the
fix/enum-values
branch
from
b11ceea to
d5ccbf8
Compare
|
I've committed some further modifications to handle corner cases like the following that I've found in my codebase: FormFieldBulkStoreRequest: {
data: {
composite_fields?: {
type: "TextSingleLine" | "TextMultiLine" | "Integer" | "Boolean" | "Date" | "Datetime" | "Reference" | "Asset";
}[] | null;
}[] | null;
}; |
|
I'm not for this approach. Currently we export consts which reference into the existing types. Instead, the consts themselves should represent the basis for the type, and the This is the approach I've already taken in #2051, so I'll prioritize making those changes backwards-compatible with the 7.x branch, which should address both #2138 and #2140. |
|
I think #2051 doesn't address #941 as it expresses the concrete values as const array, and side-steps indexed access. There's still open discussion about naming. |
|
@duncanbeevers why don't we base everything on top of the enum? export enum StatusEnum {
ACTIVE = 'active',
INACTIVE = 'inactive'
}
export type Status = `${StatusEnum}`
export const StatusValues: Status[] = Object.values(StatusEnum)
export interface components {
schemas: {
Status: Status
}
}The approach is the same of your PR but you get #941 for free. |
That's a great suggestion for a way to move forward without breaking existing enum export. I'll take a look at what it will take to get that behavior into a 7.x release. That said, I'm pushing towards eliminating non-erasable syntax in the generated types, and removing enums is an important task in that effort. |
|
@duncanbeevers I've tried v8.x but unfortunately I've found a couple of issues: depending on the enum content/length it does or doesn't generate the array and thus neither the type nor the type predicate work. openapi: v8:
Also I've noticed that we're now generating tuples instead of arrays (not sure if that change was part of your PR) but that's broken as well: openapi: v7: v8: Setting both a |
darkbasic
force-pushed
the
fix/enum-values
branch
from
b2e45cd to
94cf5fe
Compare
darkbasic
force-pushed
the
fix/enum-values
branch
from
5a33227 to
38b73b0
Compare
|
@drwpow can we give this another try? I know that @duncanbeevers 's v8 is supposed to reverse the approach, but development stalled and there are currently many issues with that branch. On the other hand my pr builds on the already existing approach and refines it, while I also managed to throw in many bug fixes. We can always depart from the current approach in v8 which will be a new major version and would justify the potential breakage. |
|
Hey just a quick note that I am also hitting issues with enum generation! I have tested the proposed fixes against my API specification and the problem of not being able to reference optional fields goes away \o/. But I have encountered a different problem! That is related to enum value generation as well. In my case I am referencing enums that where inlined in the request body part of the api specification: export const <GeneratedName>: ReadonlyArray<FlattenedDeepRequired<paths>["name"]["post"]["requestBody"]["application/json"]["variable"]> = […variants…];The correct path would be: export const <GeneratedName>: ReadonlyArray<FlattenedDeepRequired<paths>["name"]["post"]["requestBody"]["content"]["application/json"]["variable"]> = […variants…];The If not I can create a separate issue for this problem as well. Cheers, |
|
@ju6ge at this point this PR fixes at least 6 different enum related issues, so I might as well add the seventh :) |
|
No Problem here is a minimal example to reproduce the buggy behavior: {
"openapi": "3.1.0",
"info": {
"title": "ts-bug-api-gen-example",
"description": "",
"license": {
"name": ""
},
"version": "0.1.0"
},
"paths": {
"/": {
"get": {
"tags": [
"example"
],
"operationId": "handler",
"requestBody": {
"content": {
"application/json": {
"schema": {
"type": "object",
"required": [
"selection"
],
"properties": {
"selection": {
"type": "string",
"enum": [
"A",
"B",
"C"
]
}
}
}
}
},
"required": true
},
"responses": {}
}
}
},
"components": {}
}
With the following command invocation: The resulting generated code looks like this, which will not compile because the /**
* This file was auto-generated by openapi-typescript.
* Do not make direct changes to the file.
*/
export interface paths {
"/": {
parameters: {
query?: never;
header?: never;
path?: never;
cookie?: never;
};
get: operations["handler"];
put?: never;
post?: never;
delete?: never;
options?: never;
head?: never;
patch?: never;
trace?: never;
};
}
export type webhooks = Record<string, never>;
export interface components {
schemas: never;
responses: never;
parameters: never;
requestBodies: never;
headers: never;
pathItems: never;
}
export type $defs = Record<string, never>;
export interface operations {
handler: {
parameters: {
query?: never;
header?: never;
path?: never;
cookie?: never;
};
requestBody: {
content: {
"application/json": {
/** @enum {string} */
selection: "A" | "B" | "C";
};
};
};
responses: never;
};
}
type FlattenedDeepRequired<T> = {
[K in keyof T]-?: FlattenedDeepRequired<T[K] extends unknown[] | undefined | null ? Extract<T[K], unknown[]>[number] : T[K]>;
};
type ReadonlyArray<T> = [
Exclude<T, undefined>
] extends [
unknown[]
] ? Readonly<Exclude<T, undefined>> : Readonly<Exclude<T, undefined>[]>;
export const pathsGetRequestBodyApplicationJsonSelectionValues: ReadonlyArray<FlattenedDeepRequired<paths>["/"]["get"]["requestBody"]["application/json"]["selection"]> = ["A", "B", "C"];Thanks for your efforts for improving enum handling 🎉 |
darkbasic
force-pushed
the
fix/enum-values
branch
from
932db92 to
20adce9
Compare
|
@ju6ge your issue has been fixed. |
@darkbasic thank you! |
Changes
Fixes #2138 and #2140
How to Review
How can a reviewer review your changes? What should be kept in mind for this review?
Checklist
docs/updated (if necessary)pnpm run update:examplesrun (only applicable for openapi-typescript)