Unresolved any behaves different from any

[remcohaszing]

🔎 Search Terms

“unresolved any”

🕗 Version & Regression Information

• This changed between versions 5.4.5 and 5.5.2

⏯ Playground Link

https://www.typescriptlang.org/play/?&filetype=ts#code/PTAEBcE8AcFNQAoCcD20DOoC8oCGA7SAKCjlADEUVtFUMiSZ4BZAEQA0BhFfcWX5Gkw4AFAAZQsAB598AE0wBGUADIKVUAH5QAbwC+oAFzqUASiJA

💻 Code

// type Props = any

type MDXContentProps = (0 extends 1 & Props ? {} : Props)

🙁 Actual behavior

The type of MDXContentProps is any

🙂 Expected behavior

The type of MDXContentProps is {}

Additional information about the issue

When you hover over a type that doesn’t exist, the editor shows /*unresolved*/ any. In TypeScript 5.4, this type was equivalent to any. In TypeScript 5.5, it behaves slightly different. This can be seen in the playground by toggling the line type Props = any and hovering the MDXContentProps type.

If an unresolved any is assigned to another type, that type becomes equivalent to an unresolved any, except the /*unresolved*/ label is gone when hovering over it.

---

I use this pattern in MDX analyzer (https://github.com/mdx-js/mdx-analyzer/blob/[email protected]/packages/language-service/lib/virtual-code.js#L96). This allows users to optionally define props for their MDX file. This used to work great, but now everything is just inferred to any.

If there’s a better way to detect whether a type is defined, I would love to hear about it.

[RyanCavanaugh]

If you're ts-ignoreing something in declaration space, all bets are off. Do not take dependencies on discoveries made this way.

[so1ve]

Any way to detect if a type exists?

[uhyo]

Even though it is not a defect, I'm very curious which PR caused this change. 👀

[Andarist]

This changed in 5.5.0-dev.20240524, here is the diff. Likely "culprit" would be: #58610

[remcohaszing]

If you're ts-ignoreing something in declaration space, all bets are off.

I think this is fair. My example abuses ts-ignore to check whether a type exists (due to the lack of a better alternative). I think it would be totally fair for TypeScript to change this type to unknown for example, or even a special type unresolved.

However, TypeScript uses a type that looks like any on inspection, but doesn’t behave like any. This I would call a defect. Another practical example is that this type could come from a dependency if the user uses skipLibCheck true.

The following mechanism appears to work between TypeScript versions to check whether a type is any, unknown, or unresolved any. (playground)

interface Fallback {
    fallback: string
}

type Preferred = any

export type Wanted = void extends Preferred ? Fallback : Preferred

[typescript-bot]

This issue has been marked as "Not a Defect" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[remcohaszing]

I made a new playground to better show why I believe the behaviour is problematic: https://www.typescriptlang.org/play/?#code/PTAECUFMHMFcBsCGAnUBBAdgTwFABcsAHSdUAXlEWxxFABEB7SAZwDkG8BRADwEtm8ofqEA4BMABUoWBmQsG8AG6QAJqHFgqWQLgEoBhlAALBkuQAaUACNIBxEuahlvAGZPIsjIKfIGAW0rUCYlAAIXJ6JjYOHn48GjAAYSF7XgxHARS4fhsLeBIvX1FNHT1DYzdzKxs7UHheAGsSYPwiEkSKUIAyf1w40HibDGgSPAMSXLw8N1I8BhDdVESZ3QtmNyVKUABjAaHdJ1AR4Zb6ZqC6MIAGUEhuSdT7AEZQLrRQAH4D5FgSAC5QJ0Q8FWvVAoAAem8cEA