Use Standard Ruby instead of Rubocop

[mamhoff]

Summary

This (rather large) PR changes our linter from rubocop to standardrb.

The advantages are

• Standardrb does not change quite as annoyingly often
• Standardrb promises to stop us arguing about code style

See https://github.com/standardrb/standard?tab=readme-ov-file for more arguments.

I will only rebase this once if I have two approvals. It's rather cumbersome because of the large amount of change.

The two commits that introduce all the fixes are exempted from git blame through the .git-blame-ignore-revs file.

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

• I agree that my PR will be published under the same license as Solidus.
• I have written a thorough PR description.
• I have kept my commits small and atomic.
• I have used clear, explanatory commit messages.

The following are not always needed:

• 📖 I have updated the README to account for my changes.
• 📑 I have documented new code with YARD.
• 🛣️ I have opened a PR to update the guides.
• ✅ I have added automated tests to cover my changes.
• 📸 I have attached screenshots to demo visual changes.

[tvdeyen]

I like this very much. We are using standard in all our client shops with huge success. But I would like to configure rubocop with standard rules instead.

[tvdeyen]

I would prefer to keep rubocop as dependency and configure it to use standard. See https://github.com/standardrb/standard?tab=readme-ov-file#running-standards-rules-via-rubocop

That way Tools like VSCode extension ruby-lsp and other Ruby IDEs still can use their rubocop integrations

[jarednorman]

ruby-lsp can be configured to use standard as the formatter, which I find preferable than using it for diagnostics (as rubocop is normally used). There's no real use in showing cop violations if you're using that kind of set up, because they will get automatically fixed by format-on-save.

[tvdeyen]

ruby-lsp can be configured to use standard as the formatter, which I find preferable than using it for diagnostics (as rubocop is normally used)

There are many tools that only have support for Rubocop and since Standard builds on top of Rubocop it does not make any difference other than that we also support tools that only support Rubocop. I would prefer that we do not require people to have a IDE that supports Standard as well.

There's no real use in showing cop violations if you're using that kind of set up, because they will get automatically fixed by format-on-save.

Not sure what you mean with that. Rubocop is configured as default formatter and "format on save" is an independent setting in VSCode that just uses the formatter configured. This seems tangential to me. Can you elaborate?

[jarednorman]

I'm okay with your approach if you think it will generally be easier for people.

I don't know about VSCode, but when I set up projects these days (Ruby or otherwise), I try to set them up to make full use of the language server for that language. This way anyone with an editor that supports language servers gets the best possible experience.

When I set up Ruby projects, I configure ruby-lsp to use Standard as a formatter, not to provide linting errors in the editor. This leaves me the option of using Rubocop for linting if I so choose, without causing Standard's (autofixable) formatting hints to show up as linting errors in my editor, which isn't helpful, since they will be fixed automatically (assuming my editor is configured to use the language server's formatter for format-on-save, which it should be.)

Basically, formatting and linting are not the same thing, so I try to keep them separate. But, like I said, if you think configuring Standard through Rubocop will provide the best experience for most people, I won't fight you on that. I don't know how everyone else works.