A private accessibility modifier should be translated to an identifier with the prefix #

[giffeler]

TypeScript Version: 4.0.2

Search Terms:

accessibility modifier private identifier

Expected behavior:

There are two classes abc and def. In the first, a property x is marked as private with an accessibility modifier. In the second, a property y is also marked as private but with a # prefix. If instances of both classes are converted using JSON.stringify, the property is not converted in case of class def and the property y. That is the expected behavior. The translation of a property marked as private should take this into account.

[LOG]: "{}" 
[LOG]: "{}" 

Actual behavior:

Although the property x in class abc is marked as private, it is converted using JSON.stringify.

[LOG]: "{"x":"hello"}" 
[LOG]: "{}" 

Related Issues:

no

Code

class abc {
     private x: string = "hello";
}

class def {
     #y: string = "world";
}

console.log(JSON.stringify(new abc()));
console.log(JSON.stringify(new def()));

Output

"use strict";
// An accessibility modifier cannot be used with a private identifier.(18010)
var _y;
class abc {
    constructor() {
        this.x = "hello";
    }
}
class def {
    constructor() {
        _y.set(this, "world");
    }
}
_y = new WeakMap();
console.log(JSON.stringify(new abc()));
console.log(JSON.stringify(new def()));
/*
[LOG]: "{"x":"hello"}"
[LOG]: "{}"
*/

Compiler Options

{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "alwaysStrict": true,
    "esModuleInterop": true,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "moduleResolution": 2,
    "target": "ES2017",
    "jsx": "React",
    "module": "ESNext"
  }
}

Playground Link: Provided

[MartinJohns]

This is intentional and the official plan is to leave the behavior as-is: #31670 (comment)

[JoseHuertasDev]

Do you find some workaround @giffeler ?