Add new lint that bans private modifiers

[magurotuna]

TypeScript 4.3 supports private class fields with #, aligning with the ECMAScript proposal.
The hash prefix (#) will work in both TypeScript and JavaScript, while private modifier doesn't once transpiled to JS - the private keyword is finally eliminated while being converted to JS. playground
So basically we should prefer # to private for more strictness unless there is any particular reason. It would be great if deno_lint has a new lint rule to help migrate from private to #.

One concern is that this new rule is kind of controversial if it's enabled by default. Perhaps we should implement it without turning on by default at first to see if it works well for the internals of Deno.

[kitsonk]

I'm not a big fan of this. While there are now JavaScript standards for things like this, there is still a "benefit" to having type only modifiers like public, protected and private to allow some people to make code more readable, but also situations where having an "escape hatch" at runtime (while there is no escape hatch for private fields and methods (#) at runtime).

I can see that some code bases would like to enforce this rule, but I am not even 100% sure we would want to enforce it on std.

[Guergeiro]

I agree with @kitsonk. Putting my own feelings aside about the whole private and # (already explained on Deno's discord), having a private field is not necessarily a mistake, but could be and intended feature as "soft private". A nice reading material that goes back and forth between TypeScript devs and users. microsoft/TypeScript#31670

[crowlKats]

there is still a "benefit" to having type only modifiers like public, protected and private to allow some people to make code more readable

example?

[Guergeiro]

there is still a "benefit" to having type only modifiers like public, protected and private to allow some people to make code more readable

example?

Hum, the fact you'll go from public, protected, private to public, protected, #; Obviously the symbol "pops" as the different one from the keywords.

Using this.foo for every variable inside a class to this.foo + this.#bar, making it not "the same way".

[kitsonk]

example?

More readable is entirely subjective, so I am not sure an example would help you understand how using private, protected and public helps some code bases. 🤷 😕

[crowlKats]

More readable is entirely subjective, so I am not sure an example would help you understand how using private, protected and public helps some code bases. 🤷 😕

Ah my bad, i misunderstood something.

[magurotuna]

My thought is that if the objection is a matter of readability (here I define "readability" as "people feel more comfortable with a syntax because the keyword is more descriptive and they are used to it"), it's not a big deal as it will be resolved as time goes. I'm sure people will get used to # as its usage expands.
What I think really matters is private and # can have different purposes; private only works in the TypeScript context, so private methods for example could be unit-tested thanks to private looseness, putting aside here whether private methods should be tested or not.
So I'm getting to lean a little bit towards not adding this lint rule :}

[crowlKats]

In my opinion using a different name to say it is private (so using a # in front of the name) is better than having to check the definition for whether it has a private keyword or not.
Also I see people still using the private for properties even though ES private properties has been a thing for a long time, and their reason mostly is they either don't know about it or "just because".

[bartlomieju]

@kitsonk I don't have a strong opinion on this one, do you want to close it?

[kitsonk]

At this point, the rule would not be considered "best practice" and therefore wouldn't be a good idea to implement and enable.