microsoft / TypeScript

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
https://www.typescriptlang.org
Apache License 2.0
101.21k stars 12.51k forks source link

Type assertion regression in TypeScript 5.7 #60573

Open denk0403 opened 1 day ago

denk0403 commented 1 day ago

🔎 Search Terms

"typescript 5.7", "type assertions", "casting", "regression", "zod", "tsc"

🕗 Version & Regression Information

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.7.2#code/C4TwDgpgBA6gTgQzJOAeAKgPigXigbwCgoSoB9USALinUIF9DCAzAVwDsBjYASwHt2UAM7A4PdgHN4SFAAoAlDWnIIaEWMnYipKHAjBWcQfnKUINAEQWojRiw7d+gvgCMAVspQYoEAB7AIdgATISgAJQhOPjgg1HVxCQAaWEQVNAR2EExs2Vc3GnRFFJlVDC1iUj0DIwJTcHMoPJsGJij2ESgANwQAG1ZoPDzPVVltUjA4PjAARhp4yWG4BSgEUMXUCwALCB6evgtMBnkmMygAVXYAd1TvPwDgtdSvDKzsPHQAbQByCnqvgF0fP5AiFwpForF5klimlUC9slAKiQAPy1D4AaQgICg4igAGssXxmLRvr9IAD-jQLtckBhSWYARisf9sPREToCvS-v8TvVaBAOnhqTczESur1+ocAPRS0gAPWRQA

💻 Code

type Wrapper<T> = {
    _type: T
}

function stringWrapper(): Wrapper<string> {
    return { _type: "" }
}

function objWrapper<T extends Record<string, Wrapper<any>>>(obj: T): Wrapper<T> {
    return { _type: obj }
}

const value = objWrapper({
    prop1: stringWrapper() as Wrapper<"hello">
})

type Unwrap<T extends Wrapper<any>> = T['_type'] extends Record<string, Wrapper<any>> 
    ? { [Key in keyof T['_type']]: Unwrap<T['_type'][Key]> } 
    : T['_type']

type Test = Unwrap<typeof value>

🙁 Actual behavior

The type of Test is { prop1: Wrapper<"hello">; } in v5.7.

This is wrong because the Unwrap type should recursively extract the underlying type of each Wrapper.

🙂 Expected behavior

The type of Test should be { prop1: "hello"; }, like it is in v5.6.

Additional information about the issue

This issue seems related to the inline type assertion on line 14. The inference is corrected if the type assertion happens on a separate line, such as:

const strWrapper = stringWrapper() as Wrapper<"hello">;

const value = objWrapper({
    prop1: strWrapper
});

type Test = Unwrap<typeof value>
//   ^? type Test = { prop1: "hello"; }

This is a simplified version of an issue I'm seeing with some Zod schemas after upgrading to TypeScript 5.7.

Andarist commented 16 hours ago

This ia display-only bug introduced by https://github.com/microsoft/TypeScript/pull/59282 . For type printing purposes it reuses here the assertion type but it misses the fact that this type can be processed by the template of a mapped type.

How do we know it's just a display-only bug? Just inspect this:

type Test2 = Unwrap<typeof value>["prop1"]
//       ^? type Test2 = "hello"
denk0403 commented 11 hours ago

You're right that my minimal reproduction is a display-only bug. But in a larger codebase, I am seeing a very similar example break type-inference and checking for a Zod schema. What's weirder is that the larger example displays correctly in my IDE, but only errors when running tsc.

I will try to refine my reproduction above to see if I can produce the type-checking regression.

Andarist commented 10 hours ago

It would be appreciated because it should be a completely different bug. Fixing this display-only bug is just very unlikely to fix what you are describing above.

denk0403 commented 8 hours ago

@Andarist I haven't yet been able to reproduce the issue without using Zod, but here is a simplified example of the problem with Zod:

It seems like the problem also somehow relates to using "composite": true and "incremental": true, since before I split the files into their own projects, I did not see the error.

Andarist commented 6 hours ago

Ah, well - so this is actually the same issue. A type display issue like this is a type serialization issue after all and that affects emitted declaration files too (and that's what happens in your repro above). My fix should cover this already, I'll consider adding some extra tests for this too