5.0: An opaque type from other modules isn't inferred correctly

[SeokminHong]

Bug Report

🔎 Search Terms

• unique symbol
• type inference
• opaque

🕗 Version & Regression Information

• This changed between versions v4.9.5 and v5.0.2
• The nightly build also has the bug

⏯ Playground Link

Playground (v5.0.2)

💻 Code

declare const tag: unique symbol;
type Tagged<Token> = {
  readonly [tag]?: Token;
};
export type Opaque<Type, Token = unknown> = Type & Tagged<Token>;
export type Query<_V, _R> = Opaque<string>;

const q: Query<{}, {}> = 'query {}'

The opaque type that I borrowed from:

• https://younho9.dev/how-to-iterate-object-more-safely (Korean)
• https://evertpot.com/opaque-ts-types/

🙁 Actual behavior

The type of q is annotated correctly, Query<{}, {}> while the declaration of Query is on the same file. However, when I moved it to another file, the q is inferred as Query<_V, _R>. It is not reproduced on v4.9.5.

🙂 Expected behavior

The type of q should be inferred as Query<{}, {}> wherever the declaration of Query is located.

[RyanCavanaugh]

This looks like just a tooltip issue? The declaration emit shows {}, {} as expected.

[SeokminHong]

@RyanCavanaugh Could you try the following types?

type PickVariable<T> = T extends Query<infer V, infer _R> ? V : never;
type PickResponse<T> = T extends Query<infer _V, infer R> ? R : never;

const v: PickVariable<Query<{}, {}>>;
const r: PickResponse<Query<{}, {}>>;

The v and r is inferred as {} on 4.9 but unknown on 5.0.

[whzx5byb]

Even in the same file the behavior is bad in the nightly.

declare const tag: unique symbol;
type Tagged<Token> = {
  readonly [tag]?: Token;
};
export type Opaque<Type, Token = unknown> = Type & Tagged<Token>;
export type Query<_V, _R> = Opaque<string>;

const q: Query<{}, {}> = 'query {}'
//    ^?
// 5.1.0-dev.20230331: const q: Query<_V, _R>
// 5.0.2: const q: Query<{}, {}>

[Andarist]

The "same file" test case provided by @whzx5byb can be bisected to: #53246

[RyanCavanaugh]

Closing language service bugs related to the 6.0 implementation. For more information, see #62827