Types include unresolved imports will be turned into any

[so1ve]

Bug Report

🔎 Search Terms

any, unresolved

🕗 Version & Regression Information

• This changed between versions 5.0.4 and 5.1.3

⏯ Playground Link

Playground link with relevant code

💻 Code

type IsAny<T> = boolean extends (T extends never ? true : false) ? true : false;
type PickNotAny<A, B> = IsAny<A> extends true ? B : A;

// @ts-ignore
type a = import('vue').GlobalComponents
//   ^?

type GlobalComponents =
//   ^?
	// @ts-ignore
	PickNotAny<import('vue').GlobalComponents, {}>

type GlobalComponents2 =
//   ^?
	// @ts-ignore
	PickNotAny<any, {}>

🙁 Actual behavior

¯_(ツ)_/¯

🙂 Expected behavior

They should not behave differently

[so1ve]

Update: not right actually. Types include unresolved imports will be turned into any, no matter what they do. So a shorter demo: Link

[johnsoncodehk]

Just for to make it clearer:

type IsAny<T> = boolean extends (T extends never ? true : false) ? true : false;

type A = IsAny<any>; // ✅ type A = true
type B = IsAny<import('vue').GlobalComponents>; // ❌ type B = any
type C = IsAny<import('vue').GlobalComponents & {}>; // ✅ type C = true

[so1ve]

Just for to make it clearer:

type IsAny<T> = boolean extends (T extends never ? true : false) ? true : false;

type A = IsAny<any>; // ✅ type A = true
type B = IsAny<import('vue').GlobalComponents>; // ❌ type B = any
type C = IsAny<import('vue').GlobalComponents & {}>; // ✅ type C = true

Yes this also works! I can change my fix.

[RyanCavanaugh]

There are no specific guarantees on what happens when there is an error type in your program.

[so1ve]

That's true. However, the type of it is literally any, but it doesn't behave like any.

[RyanCavanaugh]

The hover shows "any" for lack of a better thing to display. It could be differentiated, but these things tend to not stick around in programs very long.

[so1ve]

Maybe you are right!
However I still prefer the former behavior. Typing it as any but it does not behave like any ismisleading. What's more, because volar imports the GlobalComponent interface from three different packages and the users maybe install one of them only (detecting whether they were installed without type system will increase workload), we rely on the former behavior to detect whether they were installed. If not, the interfaces are simply any and we can fallback to an empty interface. But in 5.1.3 we'll need a hack to fix that. In short, the old behavior is useful in some cases, but that in 5.1.3 is not intuitive.

[fatcerberus]

My suspicion is that any compile-time check that requires a @ts-ignore in the source to work at all will never be a supported use case. You are more or less in “undefined behavior” territory; here be dragons.

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