Don't emit `#private` in type declaration

[ArnaudBarre]

🔍 Search Terms

dts private

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Don't emit #private in dts for Classes with one or multiple private fields

📃 Motivating Example

When opening a dts in node_modules that contains this, because it's outside of any tsconfig, you get an annoying: Private identifiers are only available when targeting ECMAScript 2015 and higher. ts(18028) in VSCode which brings a lot of attention to a line that as no benefits for the consumer.

💻 Use Cases

1. What do you want to use this for?
2. What shortcomings exist with current approaches?
3. What workarounds are you using in the meantime?

[MartinJohns]

This is intentional. Without it the classes would turn structural, instead of nominal.

[ArnaudBarre]

Is this a TS only thing or does having a private property actually change something at runtime?

I'm not sure I fully understand what the structural/nominal implies: https://www.typescriptlang.org/play/?target=10&ts=5.9.2#code/MYGwhgzhAEBiD29oG8BQ1oGIBGYBO0AvNAIwDc60uAXkdAEwUC+qqokMC89KlNdjVC1QAzAK4A7YABcAlvAnRpAUwjSAFCMQAuFFTDVdEsQFtsygkwCUvDMAUR4IZQDoQ8AOabELmlaGsKmrqEsoA7nCI6lZWFEEaoRFc9NGxqEA

[snarbles2]

class Foo {
  #bar = 1;
  baz = 2;
}

class Foo2 {
  baz = 2;
}

class Foo3 {
  #bar = 1;
  baz = 2;
}

declare const foo: Foo;
declare const foo2: Foo2;
declare const foo3: Foo3;

let validSubFoo: Foo2 = foo;
let invalidSubFoo: Foo = foo2;
// ERROR: Property '#bar' is missing in type 'Foo2' but 
//        required in type 'Foo'.
let invalidSubFoo2: Foo3 = foo;
// ERROR: Property '#bar' in type 'Foo' refers to a 
//        different member that cannot be accessed 
//        from within type 'Foo3'.

The type Foo2 is equivalent to interface Foo2 { baz: number; }. An object does not need to be an instanceof Foo2 to be a Foo2.

With Foo, the private field is tied to the class declaration, so an object must be an instanceof Foo to be a Foo. That's why an instance of Foo3 isn't assignable to a variable of type Foo even though the declarations are identical.

[ArnaudBarre]

Ok I'm surprised by the behaviour compared to the rest of TS being a lot more duck typing.

[jcalz]

Note that private fields are class-private, not object-private. Other instances of the same class can access the private members. So you can write

export class Foo {
  #bar = 1;
  baz = 2;
  other(foo: Foo) {
    console.log(foo.#bar)
  }
}

which is emitted as

declare class Foo {
    #private;
    baz: number;
    other(foo: Foo): void;
}

Emitting #private makes the class type effectively nominal. As people have mentioned, if you don't do something like that and emit

declare class Foo {
    baz: number;
    other(foo: Foo): void;
}

then TS will allow any structurally compatible type to be assignable to Foo and you can do bad things:

const foo = new Foo();
foo.other(new Foo()); // okay
foo.other({ baz: 3, other() { } }); // runtime error, and should be a compile time error

That's a runtime error, not just a TypeScript thing.

Playground link
Bug Workbench link

[ArnaudBarre]

Ok thanks @jcalz for explaining the runtime requirement!