Figure out & document how to disable RuboCop's styling rules

[orta]

Welcome to the prettier org! So awesome.

As this project likely to live along-side RuboCop in Ruby projects we'll need to either document how to ensure that the two projects don't clash, or build something similar to https://github.com/prettier/eslint-plugin-prettier to ensure the two don't step on each others toes.

Ideas:

• Support a way to disable formatting based style rules rubocop/rubocop#6750 I just asked for their advice
• Excludes for departments? rubocop/rubocop#5678 disable all Style/*
• https://rubocop.readthedocs.io/en/latest/configuration/#inheriting-configuration-from-a-remote-url inherit a config that could ship with prettier (could have RuboCop version mismatches)

[kddnewton]

Yeah this is a really good thought. I think it might be prudent just to ship with a rubocop config. There really shouldn't be too many rules that it's violating, I really tried to stick with their style for most things. People could just inherit from their node_modules directory.

[aergonaut]

This project could ship a gem called like rubocop-config-prettier that contains rubocop.yml files disabling the style rules. Then projects wanting to Prettier along with Rubocop could use inherit_gem to inherit the config:

inherit_gem:
  rubocop-config-prettier: config/rubocop.yml

This would be like how ESLint users have to install a config plugin and update their ESLint config files to integrate with Prettier. I like the idea of shipping a gem containing a config better because it feels more "right" to install Rubocop config using gems instead of npm.

To solve the Rubocop version compatibility issue, if there are versions of Rubocop that introduce config file incompatibilities, the rubocop-config-prettier gem could start shipping alternate rubocop.yml files tailored to different versions. So say starting Rubocop 0.45 there's a compatibility change, the gem could start including a rubocop-0.44.yml file that would work for versions of Rubocop before the change, and rubocop.yml would be for the latest version.

[kddnewton]

I don’t think we necessarily need to ship a gem since we’ll already have a file on the system through the npm package. We could just ship the rubocop with the plugin.

[orta]

To take it a bit extreme: it could be feasible to ship prettier + prettier ruby + this config file as a single gem with the binaries embedded. This lets ruby devs feel like they only have one dependency manager, but makes the deploy bit more complicated. ( I do something a bit like this for danger-swift )

[kddnewton]

Oo man @orta I actually really like that idea. A lot of the pushback so far has been from ruby devs who haven't had experience with the npm ecosystem.

[AlanFoster]

Hm, I'd be interested in taking a look at that. Would https://github.com/nexe/nexe be appropriate?

[kddnewton]

I don't think we need to go so far as to bundle node. If they don't have it on their system we should just warn and fail the executable.

[idoo]

btw, any goals to use rubocop config to use rubocop's rules on the project?

[orta]

There would need to be a JavaScript implementation of the rubocop config generator (e.g. the extends from gem etc ) or a way to have rubocop export the full settings (as JSON to STDOUT or something) in order for that to work - which would be cool

[idoo]

@orta I guess it just required YML reader and mapper features, ex: something like rubocop2prettier-ruby, please correct me if I wrong

[orta]

You'd need to re-implement all of these types of features: https://rubocop.readthedocs.io/en/latest/configuration/#inheritance

[kddnewton]

While I agree that that might be nice, I think that might be overcomplicating the problem.

Rubocop already supporting inheriting config from a relative path. That means we can ship a rubocop config with this package and people can put inherit_from: ./node_modules/@prettier/plugin-ruby/rubocop.yml at the top of their config files.

In that config we should just disable every rule that is covered by the formatting rules of this plugin. As in, take away that responsibility from rubocop. I don't really see the value of linting rules with rubocop if this plugin is going to take care of it.

[idoo]

can put inherit_from: ./node_modules/@prettier/plugin-ruby/rubocop.yml

in this case, it will require additional changes for rubocop config and third-party dependencies to CI for example. Not everybody has a node on CI ;)

[kddnewton]

If folks don't have access to node then they'd probably have to inherit from a remote URL, which is feasible in rubocop. They could do that with inherit_from: https://raw.githubusercontent.com/prettier/plugin-ruby/v0.6.0/.rubocop.yml. All of this could go in the README.

[kddnewton]

I'm going to close this in favor of #116 as we're going to ship that soon, and it'll come with a rubocop config.

[AluisioASG]

Is this solved? All related issues have been closed and I can't find any guidance on configuring RuboCop. I'm using the npm package.

[kddnewton]

At the moment there aren't any known rubocop rules that plugin-ruby is violating, so you can just use a base rubocop configuration and everything should work out. If you find a rule that we're intentionally violating please let me know.

[flyerhzm]

I created rubocop-config-prettier gem to turn off all rules that are unnecessary or might conflict with prettier plugin ruby.

[kddnewton]

@flyerhzm sorry I'm not sure I understand why you would want to pull in a separate gem, why wouldn't you just open a PR here?

[flyerhzm]

@kddeisz I think it's similar to https://github.com/prettier/eslint-plugin-prettier, which isn't merged in prettier

[jensljungblad]

@kddeisz

At the moment there aren't any known Rubocop rules that plugin-ruby is violating

Prettier seems to be violating the default Layout/MultilineMethodCallIndentation cop as far as I can tell..? https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Layout/MultilineMethodCallIndentation aligned is the default but prettier seems to format with indented?

(Also interested in what is the official way of getting these two to play together)

[kddnewton]

@jensljungblad I would happily accept a PR for a rubocop config with some documentation if you're up to it.