This PR fixes a regression introduced in TypeScript 5.9 where private fields using ECMAScript syntax (#field) were being silently excluded from class expression type literals in declaration files, while traditional private/protected fields generated proper error messages.

Issue

When compiling a class expression with private fields to a declaration file, the behavior was inconsistent:

// Source code
export const ClassExpression = class {
    private traditionalPrivate = 0;  // Generated error TS4094
    #ecmaScriptPrivate = 1;          // Silently excluded, no error
    public value = 2;
};

This inconsistency meant that ECMAScript private fields could potentially slip through without proper validation.

Root Cause

The createTypeNodesFromResolvedType function in checker.ts had inconsistent handling for class expressions converted to type literals (WriteClassExpressionAsTypeLiteral flag):

• Traditional private/protected fields: Generated error but continued processing
• ECMAScript private identifier fields: Silently skipped with continue

Solution

Updated the implementation to treat both types of private fields consistently by:

1. Using isPrivateIdentifierSymbol() for reliable detection of ECMAScript private fields
2. Generating the same error message for both traditional and ECMAScript private fields: "Property '{field}' of exported anonymous class type may not be private or protected"
3. Removing the silent skip behavior to ensure consistent error reporting

// Before: Inconsistent behavior
if (getDeclarationModifierFlagsFromSymbol(propertySymbol) & (ModifierFlags.Private | ModifierFlags.Protected)) {
    // Generate error for traditional private/protected
}
if (isPrivateIdentifier(propertySymbol.valueDeclaration.name)) {
    continue; // Silent skip for ECMAScript private fields
}

// After: Consistent behavior  
if (getDeclarationModifierFlagsFromSymbol(propertySymbol) & (ModifierFlags.Private | ModifierFlags.Protected)) {
    // Generate error for traditional private/protected
}
if (isPrivateIdentifierSymbol(propertySymbol)) {
    // Generate same error for ECMAScript private fields
}

Result

Both types of private fields now generate consistent error messages, ensuring:

• Proper validation of all private members in class expressions
• Consistent developer experience regardless of private field syntax
• Prevention of invalid TypeScript syntax in declaration files

The fix maintains existing behavior for traditional private fields while bringing ECMAScript private fields in line with the same error reporting standards.

Fixes #62153.

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.