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

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:

• https://github.com/rubocop-hq/rubocop/issues/6750 I just asked for their advice
• https://github.com/rubocop-hq/rubocop/issues/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)

[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]

@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?