Just next tho the "experimental" moniker, and within an actual section about Rubocop, they in fact did provide a simple rationale anyway.
Checks out for me (even if they didn't have to provide any).
(emphasis mine)
> Why Not RuboCop?
> In most cases you likely want to use RuboCop as it has more robust support and testing. This gem is currently more experimental and focused exclusively on refactoring and AST manipulations in a more minimal sense.
In that context, the quoting was just for highlighting.
(my previous comment was probably a bit sharp; sorry – I'm just so tired of there always being this one person who has to crap all over people's personal projects)
It's also used to wrap a lot of AST tools for a talk I have next week, hence the earlier release even if it's fairly simple.
Yeah, it's still very very early in the process and I released it as I have a talk at Ruby Kaigi going over some of how this works next Tuesday, so I wanted something out even if it's simple for now.
You can, with the per-cop `EnforcedStyle` configuration key.
I hate browsing the Rubocop doc so I just put the cop name with that config key set to a bogus value, then Rubocop yells at me about the invalid value and lists the available ones.
There can be more than EnforcedStyle, e.g see these for Style/HashSyntax (scroll up for examples), which autocorrect will respect:
https://docs.rubocop.org/rubocop/cops_style.html#configurabl...
Furthermore, writing a cop is surprisingly painless.
Nothing particularly wrong with any of them, but trying to sort out what's not matching and getting an answer for now "close" a node was is a bit involved. Go far enough down that hole and you hit tree edit distance and Zhang Sha Sha algorithms.
For example, Rubocop’s default configuration insists on calling “.zero?” over using “== 0”. Not all objects have a “.zero?” method, and even if they did it isn’t guaranteed to be the same as “== 0”.
perhaps they are biased against the tool from participating in a campaign to police the name in the past.
But also, there's nothing wrong with more tools in this space. This is clearly an experiment, it should be welcomed.
Deflects the obvious without a cogent explanation because Rubocop's S-expressions are sufficiently powerful and general, already work, and don't require reinventing the wheel.