-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Deep readonly type with a nested tuple made deep writeable incorrectly extends never
#52267
Comments
A simpler demonstration of the bug here would let us look at this earlier. |
Thanks for the comment Ryan. This is a contrived example that is exhibiting the same behavior. I'm setting a depth limit of 2 on the recursion of a basic recursive mapped type and once the limit is reached, setting the value to type DeepWriteable<T> = { -readonly [P in keyof T]: DeepWriteable<T[P]> };
type Mapped<T, Count extends never[] = []> = {
[K in keyof T]: Count extends [never, never] ? never: Mapped<T[K], [...Count, never]>
};
const obj = {
level1: {
level2: {
level3: { tup1: 0 }
}
}
} as const;
type Obj = DeepWriteable<typeof obj>;
type MappedResult = Mapped<Obj>;
type test = Obj extends MappedResult ? true : false;
// ^? type test = true;
type RawResult = {level1: {level2: { level3: never; }; }; };
type test1 = Obj extends RawResult ? true : false;
// ^? type test1 = false;
const thing: test = false; // Changing the name of type test, for example, to tes, in either usage negates the type from false to true, then back to false Interestingly (and I'm not sure what the TS team's thoughts are on types like this), I was curious, just to make sure that the resulting type from the |
And just to be clear on this "renaming type" behavior, this is not using the right click -> rename symbol functionality, this is
|
This is (again) now fixed in 5.3.2. I will leave it up to the project maintainers as to when this issue should be closed. I don't know what change fixed this, and whether it is a change that will fix the problem in future versions as well (per initial comment, "...4.4.4 (correct) and 4.5.5 (incorrect) and 4.6.4 (correct)..."). |
…r my use cases), add notes about the two issues affected (microsoft/TypeScript#52267 and mmkal/expect-type#34)
Bug Report
🔎 Search Terms
never tuple
readonly tuple
change name of type
change result of type
🕗 Version & Regression Information
⏯ Playground Link
Playground link with relevant code
💻 Code
🙁 Actual behavior
A type with a multi-level nested tuple incorrectly extends itself but with a slight modification: the element of the tuple is replaced with
never
, but only when the type is created the using aboveDeepExactShape
type. When using the same type with thenever
replacement, but explicitly written out instead, it correctly does not extend.In addition, when removing the
as const
statement, it correctly does not extend. When changing the nested depth of the tuple from 3 to 2 (removing thetopLevel
property), it correctly does not extend.Finally, when changing the name of type
test
, for example, totes
, in either usage negates the type from false to true, then back to false as visible in the two-slash query and when hovering over the type (in 4.7.4 and above)🙂 Expected behavior
In both cases, the initial type,
Obj
, should not extend either the created type (fromDeepExactShape
), or the explicitly defined type, with, or without, theas const
statement included.Changing the name of a type should not result in the value of the type being different.
The degree of nesting (2 vs 3) should not change whether the type extends the created type.
The text was updated successfully, but these errors were encountered: