Regression: bug in emitted declarations involving branded types since 5.1

[GabeAtWork]

Bug Report

Code that used to compile fine in 5.0.0 now produces invalid declarations with type names suffixed in _1 which are not defined (see code below).

🔎 Search Terms

Branded type, suffix, emit

🕗 Version & Regression Information

• This changed between versions 5.0.0 and 5.1.3

⏯ Playground Link

Playground link with relevant code

💻 Code

// A simple branded type definition
export type Brand<
 Base,
 Branding,
 ReservedName extends string = "__type__"
> = Base & { [K in ReservedName]: Branding } & { __witness__: Base };

// Defining a branded type
export type BoundedInteger<
 LowerBound extends number,
 UpperBound extends number
> = Brand<number, "BoundedInteger">;

// Using in in a function
export const toBoundedInteger =
 <LowerBound extends number, UpperBound extends number>(bounds: {
 lowerBound: LowerBound;
 upperBound: UpperBound;
 }) =>
 (
 n: number
 ): BoundedInteger<LowerBound, UpperBound> =>
 // Implementation doesn't matter here
 ({} as any)

🙁 Actual behavior

// v5.1.3
// in D.TS

export type Brand<Base, Branding, ReservedName extends string = "__type__"> = Base & {
 [K in ReservedName]: Branding;
} & {
 __witness__: Base;
};
export type BoundedInteger<LowerBound extends number, UpperBound extends number> = Brand<number, "BoundedInteger">;
export declare const toBoundedInteger: <LowerBound extends number, UpperBound extends number>(bounds: {
 lowerBound: LowerBound;
 upperBound: UpperBound;
// ❌ Cannot find name 'LowerBound_1'. Did you mean 'LowerBound'?
}) => (n: number) => BoundedInteger<LowerBound_1, UpperBound_1>;
// 👆 This line

🙂 Expected behavior

// v5.0.4
// in D.TS

export type Brand<Base, Branding, ReservedName extends string = "__type__"> = Base & {
 [K in ReservedName]: Branding;
} & {
 __witness__: Base;
};
export type BoundedInteger<LowerBound extends number, UpperBound extends number> = Brand<number, "BoundedInteger">;
export declare const toBoundedInteger: <LowerBound extends number, UpperBound extends number>(bounds: {
 lowerBound: LowerBound;
 upperBound: UpperBound;
}) => (n: number) => BoundedInteger<LowerBound, UpperBound>;
// 👆 This line

[fatcerberus]

I'm confused as to why there are type annotations in "compiled" code, in any TS version. Even your Playground shows that the compiled JS code is:

export const toBoundedInteger = (bounds) => (n) => 
// Implementation doesn't matter here
({});

[GabeAtWork]

Bruce Pascoe (@fatcerberus) in the playground, you can see the definitions in the D.TS tab:

Those definitions are exported in the emitted code so that TS code that imports from this compiled code (e.g. when this is a library) can have the proper types.

So for instance, I could emit the .js code along with the .d.ts code of this library which would enable me to import the type BoundedInteger from another project's code as well as having toBoundedInteger have proper types instead of any.

[fatcerberus]

Ah, you meant the .d.ts. When you say "invalid compiled code" that makes it sound like you mean the output JS. If you had said "invalid type definitions" or "invalid declarations" that would have been clearer.

[GabeAtWork]

Bruce Pascoe (@fatcerberus) good point, I've updated the issue description to hopefully clarify that, thanks for the feedback 🙏

[GabeAtWork]

Any news on this topic? The fix seems has been available since June, anything I can help with to help get it merged?

[jakebailey]

Using the original playground link, it looks like this bug is fixed in nightly.

I bisected and figured out that I fixed it in #55820... 😅

I'll send a PR to add a test.