Allow member accessibility even for public

[torkelo]

With the scenes architecture we heavily use classes (and we use classes heavily already in core Grafana for data sources and other components).

We do allow protected and private member accessibility but not public, this to me creates unaligned/inconsistent code.

I think we should allow the public accessibility modifier. I know it is the default behavior, and it does not add any runtime behavior. It does provide great value.

It makes it super clear that the author actually thought about the intended use the function. When we only allow private/protected it's not always clear for functions that miss this keyword. Maybe the author just forgot? But a function that has the public keyword it becomes much more clear that the function is intended to be used from the outside.

It also makes code cleaner / and easier to read when all functions have modifiers:

Our current rules enforce this:

And does not allow this:

Here it is very clear that the intent of the author that the method is to be used from outside

Looking at other large typescript code bases they usually allow public keywords. The vscode code base does NOT enforce member accessibility so it's a bit inconsistent (some classes use public on all public methods some classes don't). I think that inconsistency is the only downside. The upside is that developers who want to be clear in the code they write, can and are allowed to.

[dprokop]

Agree with the argumentation. Wonder why we even threw an error for the public modifier.

Think as long as this change ain't enforced and does not cause need to update million classes, this will not ham us.

[joshhunt]

indifferent to using public (I personally wouldn't), but I dislike lint rules that enforce things that don't actually matter.

[dprokop]

but I dislike lint rules that enforce things that don't actually matter

well said @joshhunt