feat(eslint-plugin): [member-accessibility] add more options

[gavinbarron]

Hi,

This PR is a first draft of the options to allow parity with ts-lint and the member-accessibility options as discussed in #214

Overrides for parameter-properties are now included.

Docs are updated.

This feels like the rule needs to be re-named, perhaps to member-accessibility which would represent a breaking change.

[bradzacher]

I'm sorry to be a pain and flip-flop here considering that I suggested this options schema to you.

The more I think about it, the more I think it's better if we flatten the options.
Would be good to get thoughts from @typescript-eslint/core-team.

Current schema:

/*
false = don't check
true = check and use base config
object = override base config
*/
type Override = boolean | { 
  noPublic?: boolean;
};
type Options = [
  {
    noPublic?: boolean;
    overrides?: {
      accessor?: Override;
      constructor?: Override;
      method?: Override;
      parameterProperty?: Override;
    }
  }
]

Maybe it's better if it's:

type AccessibilityLevel =
  | 'explicit'  // require an accessor (including public)
  | 'no-public' // don't require public
  | 'off';      // don't check
type Options = [
  {
    accessibility?: AccessibilityLevel;
    overrides?: {
      accessor?: AccessibilityLevel;
      constructor?: AccessibilityLevel;
      method?: AccessibilityLevel;
      parameterProperty?: AccessibilityLevel;
    }
  }
]

I know that this isn't "future-proof" (i.e. it's not easy to add extra options), but it's probably better to optimise for ease of configuration for the user instead of optimising for potential future options?

[gavinbarron]

Thanks for the feedback. The new options are much nicer.
@bradzacher Do you want to re-name the rule to member-accessibility as part of this change or keep the current name to avoid a breaking change?

[bradzacher]

I don't think it's worth doing a breaking change for this.
I'm happy for it to still be called explicit-*.

If we hate the name we can always rename it later when we look at renaming a bunch of other rules.

[bradzacher]

few final comments, otherwise LGTM. Thanks for your work on this

[bradzacher]

LGMT

[mistic]

@bradzacher do you think we can move on with this PR so it would be released in the next version?

[bradzacher]

@mistic - For feature PRs, we generally look for 2 reviews from members before merging.

Myself and the other members are all volunteers, so it's not unusual that any number of us can get caught up in our professional/personal lives and not be able to work on FOSS projects for a number of weeks.
Because of that, we'll usually let it sit for around ~3-4 weeks before skipping this rule and merging with a single review

[mistic]

@bradzacher thanks for letting me know, that makes totally sense!
Thanks for your work!

[codecov]

Codecov Report

Merging #322 into master will decrease coverage by 0.11%.
The diff coverage is 90%.

@@            Coverage Diff             @@
##           master     #322      +/-   ##
==========================================
- Coverage   97.08%   96.96%   -0.12%     
==========================================
  Files          69       69              
  Lines        2537     2572      +35     
  Branches      395      408      +13     
==========================================
+ Hits         2463     2494      +31     
- Misses         45       46       +1     
- Partials       29       32       +3

Impacted Files	Coverage Δ
...-plugin/src/rules/explicit-member-accessibility.ts	90.69% <90%> (-9.31%)	⬇️