I did git push -f to fix code formatting and commit comment

Codecov Report

Merging #331 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #331      +/-   ##
==========================================
+ Coverage   97.27%   97.27%   +<.01%     
==========================================
  Files          67       67              
  Lines        2348     2350       +2     
  Branches      335      335              
==========================================
+ Hits         2284     2286       +2     
  Misses         43       43              
  Partials       21       21

@j-f1 I addressed the review comment at 040ba81

Is a fixer for this a good thing?
Esp with tools like prettier-eslint, you could accidentally silence an error and accidentally expose a function when you meant to mark it private.

IMO There are two points to this rule:

1. ensure you explicitly provide accessibility.
2. make you think about providing an accessibility.

The fixer takes care of (1), but it makes it too easy to circumvent (2).

I'm not sure if we should be providing fixers for things like this that can have a greater effect on how your code works.

@bradzacher

That's good point. I thought the same while writing tests for this and actually I have not good answer for it.
It would be dangerous to run --fix without checking warnings/errors. I'm not sure it is the normal use case.

I'd like to hear thoughts from @typescript-eslint/core-team in regards to the addition of a fixer here.

If we do want a fixer here, maybe it'd be worth making it default to private (so that it can be fixed, but so that it doesn't default to the most open modifier)?
Or would it be better to make it configurable, so the user can decide?

Note There's also #322 which is touching this rule, which will make it possible to ban using public. That option makes sense to fix, as it's like-for-like - you either define a modifier that isn't public, or you use public and can fix remove it.

It sucks that eslint doesn't have a mechanism for saying "let the user pick one of these fixers" 😢, as that'd be ideal here.

Though I'm not a core member.

I remember that I added the same autofix into the local installed eslint-plugin-typescript and used it to migrate my codebase in the past. But at that time, I had the same concern (autofix of this rule is useful, but it shouldn't fix silently), so I didn't send a PR.

@bradzacher @mysticatea @j-f1 I changed my thought. I added this since it was useful to migrate my code base with this fixer easily. But I think I should put safety first. I'm closing this. Thank you for your feedbacks and reviews!