I have just noticed that currently we include

"@typescript-eslint/explicit-member-accessibility": "error",

in recommended.json from eslint-plugin.

I propose that we remove it.

Rationale

TypeScript has always positioned itself as an extension of JavaScript. It is no secret that I think it does a bloody good job at it :)

With it being an extension of JavaScript, there is an expectation that the majority of what you write is JavaScript code, and any syntactic additions provided by TypeScript are there to give you functionality you otherwise do not have.

I strongly believe this does not apply to the public access modifier.

Classes have long been supported in JavaScript, and developers should understand how they work at runtime, regardless of if they use TypeScript or not. As we know, class properties are public in JavaScript.

The private and protected access modifiers do give you functionality you (currently**) otherwise do not have, so adding them to your otherwise valid JavaScript classes is a great capability.

The public access modifier is not only unarguably functionally redundant based on my previous assertions about developers needing to understand JavaScript classes, it is arguably visual clutter when reading the code, and makes it harder to read.

Readability is always subjective, I admit that, but I posit it is harder because having two words (public and private) both beginning with p, both of roughly equal length in front of every single class property makes them less likely to be explicitly distinguishable from one another when scanning code.

An interesting piece of context to this - I often see one of the main reasons people use to justify not using TypeScript is that it is "so different to JavaScript" and "looks like Java". This is absolutely not the case when you approach it in the way I suggest above, and leverage it as an extension to JavaScript. Having a high-profile project like this one recommend a rule like this to developers does not help with that image IMO.

Finally, the rationale for the rule given in the description in the README of the rule is very unclear.

It is conflating the decision of whether or not things should be private to a class, with whether or not public things should use a public access modifier.

Leaving off accessibility modifier and making everything public can make
your interface hard to use by others.
If you make all internal pieces private or protected, your interface will
be easier to use.

These are two completely different things:

Making everything public != Not using the public keyword

I do understand why some people might want to use this rule, and I am not advocating that we should not support it.

I am however, strongly suggesting that it is not appropriate to include it in recommended.

If people wish to provide counter-arguments to what I have said above please do, but please remember keep the focus on the justification as to why it should be in recommended.

**I say currently because of course private properties are coming to JavaScript very soon, and they have completely different syntax to what we are used to with TypeScript today. TypeScript will adapt to this in one way or another, but by leveraging public it means you are doubling down on custom TypeScript syntax in the interim, and so that is also a factor IMO