Only not risky autofixes

[schmijos]

Risky autofixes shouldn't be needed, I guess.

[coorasse]

I'd stick with Rails default. Which will run with -A.
See https://github.com/rails/rails/blob/15ddce90583bdf169ae69449b42db10be9f714c9/railties/lib/rails/configuration.rb#L138

[schmijos]

But they have a very limited ruleset. We may break things because we use way more rules.

[schmijos]

And it's not default anymore: https://github.com/rails/rails/pull/51782/files

[schmijos]

Let's see: rails/rails#53138

[coorasse]

I think this can be entirely removed anyway. Rails does it.

[coorasse]

To me is either we don't do anything, or I am ok with the -A. I have enough code coverage everywhere to catch bugs. I'd rather do that than manually adjust rubocop offenses. But if more people think otherwise I can live with that.

[coorasse]

I added some more people, so that we can come to a conclusion on this PR.

[rnestler]

I have enough code coverage everywhere to catch bugs.

It's not about your code though but about generated code for a new project, which may subtly fail.

[rnestler]

I very much agree with the comment in rails/rails#53138 (comment) that if you want to automatically apply unsafe cops you can just mark them as safe.

So running rubocop automatically should be done with -a.

[firemind]

To my understanding this is a one-off run of rubocop right after initializing a new, empty project. It seems very unlikely to have unsafe things to fix, but if it somehow does, I agree it would be better not to fix them at that point.

[ignaciosy]

I agree with Mike in that, being a one-off when creating a new project, I'd rather rubocop not break anything, as there are many initial-setup things that could already be misconfigured.
Afterwards, if bin/check goes for the risky fixes I wouldn't mind because they'd be easier to identify