You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
constx=class{
#id =10// "__#3455@#id": number; in declarations }
π Actual behavior
The class expression is rendered in declarations as declare const x: { new (): { "__#34@#id": number; }; } exposing the internal identifier of the private field.
π Expected behavior
Since we can't emit #private in an object type (like for class declarations) and we don't have class types, it's hard to come up with a solution that preserves the nominal nature of the type. I see 3 possible solutions:
Remove the type from the field (at least the internally used type will not end up being exposed) declare const x: { new (): { "__#34@#id": unknown ; }; } (partial fix)
Remove the private fields and lose the nominal nature of the class
Remove the private fields and add a unique symbol that ensures the class behaves nominally (mostly)
Third option would be the ideal one IMO. There is precedent for adding 'fake' declarations in declaration emit (_default for default exports, Name_Base for classes that use expressions in the heritage clause)
Additional information about the issue
The numeric id is not stable, and can change based on what other private fields are seen before the one emitted in the declaration
classC{ #x =1}// Comment out this line id is different exportconstx=class{
#id =10// "__#3455@#id": number; in declarations }
π Search Terms
class expressions private fields declaration
π Version & Regression Information
β― Playground Link
Playground Link
π» Code
π Actual behavior
The class expression is rendered in declarations as
declare const x: { new (): { "__#34@#id": number; }; }
exposing the internal identifier of the private field.π Expected behavior
Since we can't emit
#private
in an object type (like for class declarations) and we don't have class types, it's hard to come up with a solution that preserves the nominal nature of the type. I see 3 possible solutions:declare const x: { new (): { "__#34@#id": unknown ; }; }
(partial fix)Third option would be the ideal one IMO. There is precedent for adding 'fake' declarations in declaration emit (
_default
for default exports,Name_Base
for classes that use expressions in the heritage clause)Additional information about the issue
The numeric id is not stable, and can change based on what other private fields are seen before the one emitted in the declaration
Playground Link
(It is even worse in a language service, as the id changes each time you make a change anywhere in the file)
The text was updated successfully, but these errors were encountered: