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 On Thu, Jul 14, 2016 at 1:19 AM, Gaoyong Pan <pan.gaoy...@gmail.com> wrote: > 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. > > > On Monday, July 11, 2016 at 11:05:36 PM UTC+8, Amin Shah Gilani wrote: >> >> Initially raised on Github >> <https://github.com/rails/rails/issues/25772#issue-164738525>: >> >> 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. >> >> -- > 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-core+unsubscr...@googlegroups.com. > To post to this group, send email to rubyonrails-core@googlegroups.com. > Visit this group at https://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/d/optout. > -- 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-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
