cc @typescript-eslint/core-team

I personally like them, because I'm a sucker for being explicit.

Also coming from someone who has used C#/Java, I like being explicit because without it your code falls into the "default member accessibility" world which has a set of rules depending on where the caller is in relation to the callee.

I hate the proposed JS-standard private syntax.
I've read and understand the reasoning behind it, but I still hate it.
I would hazard a guess that typescript will look to transpiling private into that syntax?

The reason it was added originally was because the majority (if not all) of the community rulesets we looked at had it turned on. None of the ~5-10 community members that looked at the lists in the post objected to that rule, so it stuck.

I like being explicit because without it your code falls into the "default member accessibility" world which has a set of rules depending on where the caller is in relation to the callee.

Are you describing behaviour in those other languages here?

If so, I don’t think it should be a factor in this. Recommended shouldn’t be about making developers from other languages feel at home IMO

Are you describing behaviour in those other languages here?

Yes, this is how Java/C# work - there are tables you can look up to figure out what "default" actually means based on call context.
It doesn't apply to the JS/TS world, sure, but it's the reason I learned to be explicit about my accessibility modifiers, and since then I have maintained that practice because it means your code is clear and easy to understand.

Following from that, I like this rule because it forces people to be consistent in a codebase.
Without the rule, you have a mish-mash of people maybe using private/protected, but on the whole they're going to always use nothing, defaulting to public, or esp if pure JS devs hop into the codebase, you're likely to get public methods with _underscorePrefixed names.

Whilst public provides no additional functionality over nothing, the rule as a whole does because it forces you to take a second to think about the code you're writing.
It forces developers of the codebase to think about how they are setting up the contracts in their code, rather than just defaulting everything to public.

This is especially good when developing code for others to consume, as defaulting everything to public means that it's a breaking change to bring it private.

IMO enforcing a consistent accessibility modifier is a best practice, and should be recommended.

We've been debating internally at my workplace if we should be requiring or forbidding the word public. The advantages for us are clear: more "noise" vs being more likely for a developers to make things private (and I definitely like explicit over implicit). Very little of my reasoning for this rule have anything to do with my opinions of Java.

I'm not convinced that it should be recommended (mostly as it's somewhat controversial which way it should be set, although I don't really mind, it's really easy for me to configure it and turning it on makes it obvious to me that it exists) but I think this rule definitely has a lot of value.

This is just an anecdote, but personally public is almost never used because it is the default. In other languages, not making public limits the scope to the module, but neither JS or TS have module-local scope, at least not for properties.

I've only ever written it in constructor properties that are both public and mutable (so I can't use readonly), but it is a very rare use case.

IMO we shouldn’t ban valid JS unless it’s either dangerous in TS or TS has a better alternative.

My interpretation of @bradzacher's position is that the desired outcome is developers are more thoughtful about how they expose implementation details of classes.

This is an admirable goal, I do not disagree with the motivation.

However, the execution of that - forcing all methods to have access modifiers - is a very indirect way to achieve that aim. In my experience of working on the ESLint Team for the last 3 years, lint rules which try to enforce something to indirectly achieve a soft (hard to measure) outcome are what lead to developers declaring their hatred of linters and lead to a lot of frustration for everyone involved.

If they write this particular syntax, their thought process will change/improve is a difficult hypothesis to validate.

It is impossible to say how writing public will affect how people write their code. It is however, easy to quantify what a large impact the burden of adding public to every method on an existing JavaScript codebase is when migrating to TypeScript, and how different it makes otherwise valid JS. There is a clear cost, and an unclear benefit.

It also does not fit with common idioms and examples in the ecosystem, for example in Angular multiple lifecycle methods may be used on a Component's class. You won't see:

public ngOnInit(): void {}
public ngOnChanges(): void {}
public ngOnDestroy(): void {}

But that would be required by this rule. Common idioms can, of course, be based on faulty assumptions etc, but they should not be discounted when evaluating the impact of a deviation imposed by a linting rule.

Let's also not forget that until private properties land in JavaScript, the notion of private is a false friend and should not be overvalued. Your properties are there at runtime, they are exposed. This is JavaScript.

I see the question of whether or not something should be in recommended as:

"Would the ecosystem be clearly better off if everyone wrote their code this way?"

This is a very high bar, but it is definitely worth living up to wherever possible. With its clear cost and unclear benefit, forcing developers to deviate from JavaScript and write public does not meet that standard IMO, and it should be available for people to opt in to only if they want to.

My interpretation of @bradzacher's position is that the desired outcome is developers are more thoughtful about how they expose implementation details of classes

That's it :)
It only really works in conjunction with code reviews though. If nobody is reviewing your code then the onus is entirely on you to not just shut the rule up with public everywhere.

I'm happy to remove it - I'm not overly opinionated for a recommended config (I've always been one to manually define my own rulesets). I tried to base it off of a combination of what the TS team does in their docs + what other ts eslint configs had done.

Technically would be a breaking change though.
Would be good to somehow get more signal from the greater community on this.

Why would it be a breaking change? The only change would be a decrease in the number of reported issues when using the recommended config. If people want those reports back, they can simply enable the rule.

The recommended config is rather opaque from an end-user's perspective.
They mightn't realise if we turn off a rule in the recommended config.

what do you think about making 3 configs:

• base:
  • set parser
  • disable eslint core rules (no-unused-vars etc...)
  • set parserOptions
• recommended:
  should extends base
  • all rules which prevents errors and unintended behavior
  • if rule is highly opinionated it should not be listed as recommended
• code-style (not sure about name):
  should extends recommended
  rules that helps keep your code consistent
  • indent
  • explicit-member-accessibility
  • and so on

with that we are giving users a little more granularity and easier way to set up environment

Also note that actual JS syntax for private is gonna be # so the recommended thing should be to stop using TS syntax completely to avoid refactoring in the future

@phaux - not necessarily.. it depends on how typescript handles the transpilation.

They could very well transpile private foo to #foo, meaning you don't have to refactor anything.

They could very well transpile private foo to #foo, meaning you don't have to refactor anything.

Unfortunately not ...

microsoft/TypeScript#9950 (comment)
microsoft/TypeScript#31670 (comment)

That's an interesting read, thank you.
I'd have to read more to understand the differences between the two, but it seems like the typescript team are saying that there's difficulties in that transpilation.

Which makes me think that there is definite use cases for continuing to use private instead of #?
Need to read more!

The difference is that private foo just pretends that you can’t access the foo property when you shouldn’t be allowed to (i.e. if you consume TS code in plain JS, you can access and modify something.foo), whereas #foo actually enforces the guarantees that TS’s type system enforces for private, meaning that JS code can’t access something#foo unless it’s supposed to.

But what I'm wondering is - why you ever not use private #foo/#foo instead of just private foo?

No, but it would be a breaking change to transpile private foo to #foo.