[Proposal] [Feature Request] Make new rails apps rubocop compliant

[Amin Shah Gilani]

Initially raised on Github:

I understand that the project disallows cosmetic changes but:

• Some projects follow stylistic rules (even rails does)
• Rubocop is quick to set up, and configure (even rails uses it)
• Rubocop is modular, you can enable, disable or even configure cops
• The best way to let devs tailor their lint compliance is by generating code compliant with all the cops
• Currently, for initial generations, additional work is required in new rails project to ensure lint compliance.

If I could take the time to ensure rails new app generates a rubocop compliant skeleton app, will the maintainers consider merging the code?

This will essentially reduce the time it takes to scaffold a project and would be a backwards compatible feature.

This could be extended to make sure all the code made by `rails generate` is also lint compliant.

[Xavier Noria]

What is a compliant skeleton app?

[Mohamed Wael Khobalatte]

We run rubocop on various Rails repositories, with great results, but I remember the time spent turning off the default options that don't work for us is non-trivial (Granted, rubocop came later, bigger team, so on). If anything, you should pick the smallest subset possible of all the available cops, the ones that will pass by default. Even in this case I am not sure if it is worth it, as you create a dependency on rubocop versions even if it is not strictly speaking a dependency of Rails, forcing you to revisit whatever code you intend to write now.  

On Mon, Jul 11, 2016 at 11:29 AM, Xavier Noria <f...@hashref.com> wrote:

What is a compliant skeleton app?

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

--

Wael Khobalatte

[Xavier Noria]

I don't use RuboCop in personal projects. In my consultant work some clients do, some don't. Those that do have different configuration files because no two Ruby teams have the same preferences (that's probably a theorem). Even more, for Rails to be consistent it should emit a config file that conforms to Rails conventions, like indentation after `private` and friends.

In my experience, variation in usage is too wide. Generating RubyCop support for new applications would not be a good default in my opinion, better leave to each project the choice.

[Gaoyong Pan]

I like this idea. It would be nice newly generated rails app could pass the rubocop checking with its default configuration. I also suggest adding two more options to .rubocop.yml,
TargetRubyVersion and Rails/Enabled: true. Together this makes them default configuration for new rails app rubocop config. Rails app developers can customize them per their own preferences later. In this way, everybody has a very good base to start on.

[Chad Woolley]

Re: "I don't use RuboCop in personal projects. In my consultant work some clients do, some don't. Those that do have different configuration files because no two Ruby teams have the same preferences"

This is a red herring.  Most of the Rubocop failures against the standard Rubocop config are due to fairly non-controversial formatting stuff, like using single quotes for non-interpolated strings.  Of course I have a custom config like everyone else, but only for things I can't comply with, e.g. some obscure formatting where I can't convince my editor's autoformat to comply with.  But I've never overridden the rules that are violated in a generated rails app.

If an existing person or team DOES use Rubocop, AND is in the habit of generating new Rails projects, AND they somehow have a reason to change these standard config rules, then it's completely reasonable to expect them to fix it after generation.

But that should be a pretty rare case, and no reason to inflict the need to edit every generated rails project on everyone else who DOES stick to a mostly standard Rubocop config.

Thanks,

-- Chad

[Matthew Draper]

> On 16 Jul 2016, at 02:00, Chad Woolley <thewoo...@gmail.com> wrote:
>
> Most of the Rubocop failures against the standard Rubocop config are due to fairly non-controversial formatting stuff, like using single quotes for non-interpolated strings.

This is, in fact, an excellent example of a controversial rule.

Conclusions aside, this article is a good aggregation of links demonstrating varied opinion:

http://anti-pattern.com/always-use-double-quoted-strings-in-ruby


As a bonus, here’s an explicit acknowledgement that it is not Rails style:

https://github.com/bbatsov/ruby-style-guide/issues/96#issuecomment-5022719


Rubocop defaults to following Bozhidar’s Ruby Style Guide, which is a perfectly reasonable choice given he wrote it.

But said style guide is a combination of: actual community style conventions; semi-arbitrary decisions on matters that lack consensus (again, perfectly reasonable — a style guide with few firm opinions would not be terribly useful); and a number of rules which seem to be Bozhidar’s personal opinions, overriding the community conventions of the time, based on his belief that they’re Better.

(As, over time, teams have adopted the guide wholesale, whether through a belief it truly represents common style or through disinterest in arguing the point, rules in group 3 have naturally migrated to group 2.)

I personally consider it unfortunate that the guide purported to be as universally-representative as it did, and yet did not distinguish between those groups, especially in earlier versions (it now has more “do A or B, but pick one” statements than it once did). But again, this is a prerogative of authorship.



Rubocop also has support for autocorrecting many style infractions, including choice of quotes.


Matthew


--
mat...@trebex.net

[Xavier Noria]

We are talking here about whether to add RuboCop by default to newly generated apps. This would then extend to a discussion about the configuration, whether to integrate with the test suite, etc.

The answer, at least my answer, is that my experience says this is not something I want to add as a dependency to new apps. And Rails should not have as a goal to generate code that passes any particular set of RuboCop rules, that would be sticking to one particular set of rules, and precisely the only rules we have to follow are our own.

In my view Rails has no business enforcing or pushing RuboCop. No saying some people may love it, some companies may have it as a requirement, etc. Not a statement about RuboCop in particular. I am talking from the point of view of a maintainer that weights the impact on all the user base and the derivations and believes it is not a good idea.

Each project is free to depend on it, and if their chosen configuration needs editing generated files... well, that's your choice!

[Andrew Kaspick]

Why can't a gem be created that contains  rubocop compliant generators and that is used? I see this as a slippery and unnecessary slope to be included directly in rails imo.

[Chad Woolley]

Yes, I now see the points against including it are valid, but it would be good to see a gem that overrides the generators to generate compliant apps.

[Greg Navis]

We can invert the problem and make rubocop support multiple styles. I think this would be a better idea community-wide as it'd enable more projects to use rubocop without having to reformat a significant part of their code bases.

I'm curious what you think.

[Chad Woolley]

That was one thought I had.  That would be the easiest first pass at a gem that made the generators "compliant" - just make it add a rubocop config that allowed the default generated rails code to pass.

On Mon, Jul 18, 2016 at 6:16 AM, Greg Navis <con...@gregnavis.com> wrote:

We can invert the problem and make rubocop support multiple styles. I think this would be a better idea community-wide as it'd enable more projects to use rubocop without having to reformat a significant part of their code bases.

I'm curious what you think.

--