Repository navigation
Optional nested readonly type changes type of property adding undefined #55058
Description
Bug Report
I was working with a library which reported that a property had an additional value of undefined, and the author of the plugin claimed that the error went by removing readonly. After investigating I found the following, which I found confusing.
The framework we use (vue) has a function for marking objects as deeply readonly:
export declare function readonly<T extends object>(target: T): DeepReadonly<T>;
export declare type DeepReadonly<T> = T extends {} ? {
readonly [K in keyof T]: DeepReadonly<T[K]>;
} : Readonly<T>;When wrapping an object with optional properties:
export declare class User {
a?: string;
b: string;
}
export const user = readonly(new User() )... the exported types have an additional undefined at the type definition, even though it wasn't allowed in the original type.
export declare class User {
a?: string;
b: string;
}
export declare const user: {
readonly a?: string | undefined;
readonly b: string;
};🔎 Search Terms
extra undefined, nested readonly, deepreadonly
🕗 Version & Regression Information
- This is the behavior in every version I tried.
⏯ Playground Link
Playground link with relevant code
💻 Code
This was the smallest I could reduce the code to and still see the compiler doing the unexpected:
export declare function readonly<T extends object>(target: T): DeepReadonly<T>;
export declare type DeepReadonly<T> = T extends {} ? {
readonly [K in keyof T]: DeepReadonly<T[K]>;
} : Readonly<T>;
export declare class User {
a?: string;
b: string;
}
export declare type ReadOnlyUser = DeepReadonly<User>
export const user = readonly(new User() )🙁 Actual behavior
The code above is transformed to the following types. The generated type for the variable user is incompatible with the exported class User, because it adds undefined as type to the type of the optional parameter of the class.
export declare const user: {
readonly a?: string | undefined;
readonly b: string;
};🙂 Expected behavior
The types of User and user should be identical, the latter should just have all props as readonly, but there should be no other changes to the type.
export declare const user: {
readonly a?: string;
readonly b: string;
};
Activity
MartinJohns commentedon Jul 18, 2023
What is
exactOptionalPropertyTypesset to? If it's set tofalsethere's no difference between the types. The additionalundefinedmakes no difference.SimonSimCity commentedon Jul 18, 2023
Sorry, forgot to mention 😅 I've set
exactOptionalPropertyTypestotrue, as recommended.fatcerberus commentedon Jul 18, 2023
I assume the problem is that, for optional properties, regardless of
eOPT,T[K]evaluates toP | undefined, because that's the type you will get if you read from that property. In other words:which wouldn't hold if the
undefinedwasn't included for optional properties.RyanCavanaugh commentedon Jul 18, 2023
This behavior follows from the definition of the type, as Bruce Pascoe (@fatcerberus) points out.
Turning on EOPT, I see the desired behavior. Can you clarify?
SimonSimCity commentedon Jul 19, 2023
Oh! The generated types are different based on this option 🫣
Ryan Cavanaugh (@RyanCavanaugh) Ok, let me explain ... The example itself is a bit more complicated 😊 Some of the code is taken from a code-basis, where I have no control over - an external library. This external library generates the types and does not have
exactOptionalPropertyTypesenabled.I, in my project, want to have
exactOptionalPropertyTypesenabled, which is why I am getting this error.Here's the example. I don't know about vue, but the other plugin (Auth0Vue) has it disabled. This means, the example is best split into two:
Is this expected? Well, I would assume, that projects are independent by best effort. Now this project forces me to disable
exactOptionalPropertyTypesfor my project, if they do not enable it or change the code (as of now, they've merged changes for the latter by removing thereadonlywrapping).SimonSimCity commentedon Jul 19, 2023
I can't really come up with a good solution here. A project would almost have to know with which parameters a set of types are built, right ..? 🙈
When I take my playground example, and flip the switch for
exactOptionalPropertyTypesfromtruetofalseand back again, the only thing that changes is the propertyuser.a, even thoughUser.aalso implicitly could beundefined, which is not stated in the generated types. This could is a type-insecurity when now using it in a project havingexactOptionalPropertyTypesenabled.Maybe I'm also just going way off track ... I'm just trying to find a good solution 😇
fatcerberus commentedon Jul 19, 2023
Simon Schick (@SimonSimCity) This is a known pain point: see #54212 and #49886
typescript-bot commentedon Jul 23, 2023
This issue has been marked as "Question" and has seen no recent activity. It has been automatically closed for house-keeping purposes.