An accessibility modifier cannot be used with a private identifier

[jonlepage]

Suggestion

i think ts should allow the modifier private on a private identifier.
for keep a kind of design correlation in a project.

Actually change a public identifier to #private , lint error on all ts private modifier

Is there a way to ignore this error in tsconfigu ?

export class A  {
	private #foo= new foo();
}

i color all my accessibility modifier for fast nav, but private identifier lint error with the private accessibility modifier !

🔍 Search Terms

An accessibility modifier cannot be used with a private identifier

[sandersn]

#private and private are mutually exclusive, like public and private. Typescript doesn't allow combining those either. It's confusing because they do nearly the same thing, but that's even more reason to keep them separate.

[jonlepage]

#private and private are mutually exclusive, like public and private. Typescript doesn't allow combining those either. It's confusing because they do nearly the same thing, but that's even more reason to keep them separate.

ho oki, i will take a look on doc to understand more !
thanks for your fast answer and your reason to keep this separate , i will close !

[revolter]

like public and private

Not quite, since they're not opposites.

they do nearly the same thing

Not that nearly, since private is enforced at compile time, and #private is enforced at runtime: https://stackoverflow.com/a/59641565/865175.

[ctsstc]

I wanted to know if this transpiles down to a #privateProperty I guess it does not unfortunately even with the target of esNext.

I know there's deep history here. The private keyword has been utilized by TypeScript well before JavaScript even had private properties or even classes. I would expect if the TSConfig target was modern enough that it should be transpiling private into a #privateProperty. But then we would need to make sure there wasn't any conflict. It seems that if we have the language feature now and have the runtime safety of OOP private access that it should be utilized. It makes me wonder if older transpilation targets have never isolated the values, or if that was lost in the transition to classes?

If we look at the ES3 target transpilation, we'll see that transpilation did indeed protect it's scope a bit more it seems by abstracting it out into a variable. This would just depend what context this was then ran it, but it wouldn't expose the property on the class instance.

[RyanCavanaugh]

@ctsstc see #31670