Figure out & document how to disable RuboCop's styling rules about plugin-ruby HOT 22 CLOSED

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.

from plugin-ruby.

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

from plugin-ruby.

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 )

from plugin-ruby.

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.

from plugin-ruby.

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.

from plugin-ruby.

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

from plugin-ruby.

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.

from plugin-ruby.

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.

from plugin-ruby.

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.

from plugin-ruby.

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

from plugin-ruby.

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.

from plugin-ruby.

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

from plugin-ruby.

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

from plugin-ruby.

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

from plugin-ruby.

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

from plugin-ruby.

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 ;)

from plugin-ruby.

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.

from plugin-ruby.

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.

from plugin-ruby.

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.

from plugin-ruby.

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

from plugin-ruby.

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

from plugin-ruby.

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

from plugin-ruby.