Add eslint rule for correct accessibility modifier usage

[Tyriar]

[Tyriar]

This is very easy to accomplish with this eslint rule: https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/explicit-member-accessibility.md

I've actually become more fond of avoiding public all together for members now as it makes it more obvious whether members are private or protected. @jerch interested in your thoughts, we can go either way requiring public or requiring no public by using one of these rules:

    "@typescript-eslint/explicit-member-accessibility": [
      "error",
      {
        accessibility: "no-public"
      }
    ]

    "@typescript-eslint/explicit-member-accessibility": [
      "error",
      {
        accessibility: "explicit"
      }
    ]

And then running yarn lint --fix to automatically updates the hundreds of cases. This commit is an example after running --fix, we'd want to merge it asap after running though Tyriar@76636c6

[jerch]

@Tyriar Well not quite sure which works best here in terms of "easy coding". In TS I tend to treat everything not explicitly marked as public as private. So no-public might do here. I would prefer "explicit" in the end (to avoid my own sloppiness), but not sure if this causes to many frictions atm.

Ideally for me would be these general rules:

• enforce explicit access declarations for any class member in TS - This is abit noisy, but helps with coding discipline by expressing your true intentions for member XY.
• one leading underscore for pure private members - This does not help much in TS space, but later in JS to still identify pure privates. (This is basically a convention from langs, that dont support access declarations in the first place like Python.)
• camelCase class members, PascalCase class names itself - These are imho just popular conventions, that work nicely. Some langs like python favor C style underscore names, but meh, idc much here, at least it should be unique across the codebase. For TS camelCase seems more appropriate.
• UPPER_CASE with underscore for consts, or things that should not mutate at runtime (like enums, const primitives, frozen objects?)

On module level I would apply the same rules, except for "module private" members - imho an underscore is not needed here (and no problem later in JS later on as it would not occur there as an accessible name).

[Tyriar]

I would prefer "explicit" in the end (to avoid my own sloppiness)

Let's go with that then, eslint will force you to say either public or private, not accidentally leave members public. It's also keeping what we've been doing (mostly) so not much change.

but later in JS to still identify pure privates

"Pure privates" get # prefixes as they're forced by the language?

I think the rest of the rules are basically enforced, with the exception of UPPER_CASE vs camelCase which is intentionally flexible to cover some edge cases.

[Tyriar]

For explicit there isn't an auto fix by design as since the rule is about explicitly considering public members: typescript-eslint/typescript-eslint#503

[Tyriar]

I learned by doing this that this:

constructor(readonly foo)

Implies:

constructor(public readonly foo)

So fixed some stuff 🙂

[jerch]

I learned by doing this that this:

constructor(readonly foo)

Implies:

constructor(public readonly foo)

So fixed some stuff slightly_smiling_face

Oh well, thats abit surprising. Why the heck does readonly mess with access level at all?

"Pure privates" get # prefixes as they're forced by the language?

Not sure what you mean by that, is there some additional name mangeling going on? What I meant in the first place - I know from my own quick diving into foreign APIs, that I tend to see non underscored members as public (like in Python or JS), inviting to play with it. Any underscore member gets flagged as "oh, you better dont touch this thingy". Ofc for pure TS projects/libs this is no issue, as it has strong access typing. But as soon as the project gets used from JS side, this gets more flakey and I appreciate the underscore hint there.