-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] typescript-fetch since 7.4.0 ignores nullable: true #18288
Comments
i wonder if you can do a git bisect to identify the commit causing the regression? |
I will try my best to find some time for that but not sure when. |
I believe this PR broke it: |
Was this change intended? This breaks our PATCH requests as we distinguish between undefined and null in the api. |
@l0gicgate is correct that #17798 introduced this bug, specifically this change (and the others like it throughout the same PR). To JavaScript and TypeScript, If you'd like to denote a property as also being able to hold a interface Foo {
nullableField: string | null;
}
// Fine: can be `null`
const foo1: Foo = { nullableField: null };
// Error: cannot be `undefined`
const foo2: Foo = { nullableField: undefined };
// Error: field has to be present
const foo3: Foo = {}; Technically if a field is expected to be present but could hold an interface Foo {
presentButMaybeUndefined: string | undefined;
}
// Fine: can be `undefined`
const foo1: Foo = { presentButMaybeUndefined: undefined };
// Error: field wasn't optional (`?`) so it has to be present
const foo2: Foo = {}; I think the most correct way to capture all possible use cases if a field is optional (in the OpenAPI sense) is to annotate it field with both interface Foo {
couldBeUndefined?: string | undefined;
}
// Fine: field is optional
const foo1: Foo = {}
// Fine: field can explicitly hold `undefined`
const foo2: Foo = { couldBeUndefined: undefined }; However, if the types prior to #17798 were working then it's probably fine to just revert the change and avoid possibly causing new bugs by explicitly adding The correct behavior should be: interface Foo {
requiredNonNullable: string;
requiredNullable: string | null;
optionalNonNullable?: string;
optionalNullable?: string | null;
} |
this issue is addressed here: #18887 |
Bug Report Checklist
Description
Hello since update to 7.4.0, nullable: true anotation is ignored and typescript generated interface doesn´t include "| null"
openapi-generator version
7.4.0
OpenAPI declaration file content or url
Generation Details
I generate it using npm package: "@openapitools/openapi-generator-cli": "^2.13.1".
With command
npx openapi-generator-cli generate
with following configurationSteps to reproduce
If you generate source code from this provided yaml with 7.4.0 you will get generated output where ResponseObject.ts is defined like this:
but with all previouse versions it was like this
It looks like version 7.4.0 started to ignore nullable: true anotation.
Related issues/PRs
Maybe related to this issue ? #18005
Suggest a fix
Output should look like this:
The text was updated successfully, but these errors were encountered: