You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
=== /a.ts ===
class A {}
>A : A
export type B = A;
>B : A
=== /b.ts ===
import { B as C } from './a';
>B : any
>C : any
Note that during the normal course of checking, everything works fine, because we don’t ask for the type of the import specifier. If someone were to useC, we’d ask for the type of the type reference, and we’d start by resolving the alias all the way to its origin. So only when the baseline writer specifically asks for the type at B and C do we hit this bug. So, it’s fairly unimportant. I investigated this and an opening the issue to document that some any readouts in #35200 are exhibiting some existing poor behavior, and fixing it there would be out of scope.
The text was updated successfully, but these errors were encountered:
Baseline test:
Types baseline:
Note that during the normal course of checking, everything works fine, because we don’t ask for the type of the import specifier. If someone were to use
C
, we’d ask for the type of the type reference, and we’d start by resolving the alias all the way to its origin. So only when the baseline writer specifically asks for the type atB
andC
do we hit this bug. So, it’s fairly unimportant. I investigated this and an opening the issue to document that someany
readouts in #35200 are exhibiting some existing poor behavior, and fixing it there would be out of scope.The text was updated successfully, but these errors were encountered: