Skip to content

Type assertion regression in TypeScript 5.7 #60573

Description

@denk0403

🔎 Search Terms

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

🕗 Version & Regression Information

  • This changed between versions 5.6.3 and 5.7.2

⏯ 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.

Activity

  1. Andarist commented on Nov 24, 2024

    @Andarist
    Contributor

    This ia display-only bug introduced by #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"
  2. denk0403 commented on Nov 24, 2024

    @denk0403
    Author

    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.

  3. Andarist commented on Nov 24, 2024

    @Andarist
    Contributor

    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.

  4. denk0403 commented on Nov 24, 2024

    @denk0403
    Author

    Mateusz Burzyński (@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.

  5. Andarist commented on Nov 24, 2024

    @Andarist
    Contributor

    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

  6. locked as resolved and limited conversation to collaborators on Oct 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    BugA bug in TypeScriptFix AvailableA PR has been opened for this issueHelp WantedYou can do this

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions