Refactor rubocop action

[davidwessman]

No description provided.

[andrewshadura]

While neither GitHub not GitLab support this natively yet, how about adding .git-blame-ignore-revs file with the 27912c7’s full hash (similarly to e.g. this).

[davidwessman]

While neither GitHub not GitLab support this natively yet, how about adding .git-blame-ignore-revs file with the 27912c7’s full hash (similarly to e.g. this).

Good idea 🙂
I added the file, lets hope that Github will support something similar in the future.

[m0n9oose]

@davidwessman can you explain why exactly Standard is any better than good ol' Rubocop? I agree, we need to update it and maybe adopt some changes in rules, but I don't see why we need to replace it.

I was thinking about using the Rails approach https://github.com/rails/rails/blob/4a78dcb326e57b5035c4df322e31875bfa74ae23/.github/workflows/rubocop.yml

[davidwessman]

I started with doing that, but then I ran into the outdated rubocop config, and did not know how to update the rules.

The main reason to use standard is to avoid having to device on all the new rules and get a nice default.

I can fix an updated action using rubocop directly without changing the .rubocop.yml

[davidwessman]

https://github.com/testdouble/standard#why-should-i-use-ruby-standard-style

[m0n9oose]

@davidwessman i don't see the point of this tool. Rubocop has default settings as well. You don't have to configure every single cop. Also, as far as I see, this is just a wrapper for Rubocop.

I don't mean to look into new tools, but this one seems just a wrapper with minimal value. Not to mention we'll have to update the whole codebase to adopt the new code style.

Let's stick with Rubocop and just update it.

[davidwessman]

@m0n9oose Now it uses rubocop with the same config all the way 🙂