Skip to content

Bloomberg feedback for 5.9 #62156

Open
Open

Description

Comment

We evaluated the 5.9 RC releases and 5.9 is a low impact release for us.

# Change Affects Release notes Packages affected PR / Issue
1 Class expressions with private fields produce invalid .d.ts output Declaration Emit No <1% #62153
2 Promise.all over constant tuples no longer infers tuple Type Checking No <1% #62071
3 JavaScript emit removes parentheses around ?? in conditional expressions Emit No <1% –
4 Better detection of always-true errors in ?? expressions Type Checking No <1% –

Class expressions with private fields produce invalid .d.ts output

With TypeScript 5.9, the following code:

export const ClassExpression = class {
    #context = 0
};

Produces invalid declaration output:

export declare const ClassExpression: {
    new (): {
        #context: number;
    };
};

5.8 output was also incorrect but at least syntactically valid:

export declare const ClassExpression: {
    new (): {
        "__#1@#context": number;
    };
};

❗This seems like a major regression, since emitted declarations are now invalid.
Tracked in #62153

Promise.all over array literal no longer infers a tuple

This issue is easier to reproduce than the linked ticket may suggest. It affects any use of Promise.all in the return position of a .then() that chains from a promise resolving to an array:

const p = Promise.resolve([]).then(() => {
    return Promise.all([0, ""]);
});
const test: Promise<[number, string]> = p; // error

This now fails to infer a tuple and infers Promise<(string | number)[]> instead.
While we can work around this issue by assigning the result of Promise.all to an intermediate variable, this does seem like an unfortunate regression.

Tracked in #62071

JavaScript emit removes parentheses around ?? in conditional expressions

In some cases, parentheses are removed from nullish coalescing expressions in emitted JavaScript. This change seems benign.

(test ?? true) ? A : B

Becomes:

test ?? true ? A : B

Better detection of always-true errors in ?? expressions

We observed two new diagnostics related to always-true ?? expressions.
The improved detection highlighted logic errors that were previously missed.

Activity

  1. RyanCavanaugh commented on Jul 31, 2025

    @RyanCavanaugh
    Member

    The 5.8 behavior of Promise.all is kind of surprising to me -- normally our inference rules would produce either [0, ""] (like in as const) or (string | number)[] (like in a let initialized with an array).

    I would recommend this as a workaround:

    type Tuple2 = [unknown, unknown];
    const p = Promise.resolve([]).then(() => {
        return Promise.all([0, ""] satisfies Tuple2);
    });
    const test: Promise<[number, string]> = p; // ok

    or

    // Make as long as needed
    type Tuple = [unknown?,unknown?,unknown?,unknown?,unknown?,unknown?,unknown?,unknown?];
    const p = Promise.resolve([]).then(() => {
        return Promise.all([0, ""] satisfies Tuple);
    });
    const test: Promise<[number, string]> = p; // error
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    DiscussionIssues which may not have code impact

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions