plugin clashes with RuboCop's Style/SingleLineDoEndBlock and Style/BlockDelimiters

[maxjacobson]

Hello there!

I'm working on a project which is using this plugin to format ruby code along with RuboCop for additional linting and style consistency.

We're following the documented "Usage with RuboCop" procedure of inheriting from the .rubocop.yml provided by this plugin.

Nevertheless, we've noticed an example where the two tools clash with each other. I've made a sample repo to reproduce this here: https://github.com/maxjacobson/prettier-plugin-ruby-example/

I'll summarize the gist of the issue here as well.

Expected behavior:

Given a file app.rb

expect do
  foo
end.to change(Bar, :baz, 1)

When I run bundle exec rubocop --auto-correct && node_modules/.bin/prettier --write .

And I run bundle exec rubocop

Then zero RuboCop offenses will be reported

Actual behavior

prettier changes that file to

expect do foo end.to change(Bar, :baz, 1)

And rubocop finds these offenses:

$ bundle exec rubocop
Inspecting 2 files
.C

Offenses:

app.rb:1:1: C: [Correctable] Style/SingleLineDoEndBlock: Prefer multiline do...end block.
expect do foo end.to change(Bar, :baz, 1)
^^^^^^^^^^^^^^^^^
app.rb:1:8: C: [Correctable] Style/BlockDelimiters: Prefer {...} over do...end for single-line blocks.
expect do foo end.to change(Bar, :baz, 1)
       ^^

2 files inspected, 2 offenses detected, 2 offenses autocorrectable

It seems that those two RuboCop cops, Style/SingleLineDoEndBlock and Style/BlockDelimiters, clash with this plugin. RuboCop wants this snippet to be three lines and prettier wants this snippet to be one line, so the file keeps bouncing back and forth trying to please both masters.

Brainstorming options

• the plugin's .rubocop.yml could disable those two cops
• perhaps the plugin's .rubocop.yml could configure those two cops to be better aligned with this plugin's behavior
• perhaps the plugin shouldn't touch this code at all? I'm not sure that the one line version is actually better than the three line version. It's not particularly idiomatic to have single line do end blocks, is it?
• or if this plugin really does want to squash this block onto one line, perhaps it should use a curly-brace-delimited block instead of a do/end block. That would avoid tripping those RuboCop cops

one more question...

Out of curiosity, I'm wondering if this project is still being worked on? It overall is pretty stable and very useful, but it has been pretty quiet release-wise all the same.

Many thanks!