jakeonrails/fix-db-schema-conflicts

Rubocop 0.54 incompatibilty

ideasasylum opened this issue · 6 comments

ideasasylum commented

I updated rubocop to 0.54 in an attempt to resolve #26 and received this error:

$ rails db:migrate RAILS_ENV=test
Dumping database schema with fix-db-schema-conflicts gem
Error: The `Style/TrailingCommaInLiteral` cop no longer exists. Please use `Style/TrailingCommaInArrayLiteral` and/or `Style/TrailingCommaInHashLiteral` instead.
(obsolete configuration found in /Users/jamie/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/fix-db-schema-conflicts-3.0.2/.rubocop_schema.49.yml, please update it)

I was about to start working on the required changes when I realised that it wasn't clear what the strategy should be.

.rubocop_schema.49.yml is used for rubocop installs >= 0.49. So should this gem…

  1. add a new .rubocop_schema.XX.yml schema file every time the rubocop schema changes (entailing more checks in the code)
  2. Maintain support only for the most recent rubocop?

I'm not sure how often rubocop changes their schema but two incompatibilities between 0.48 and 0.53 seems an annoying rate.

jakeonrails commented

I just looked at the forks of this project and saw that most are related to Rubocop version upgrades and/or style choices that people don't like in their project.

Perhaps the best way forward is to rely on the default Rubocop style when none is provided by a Rails project bundling this gem, and then use the Rubocop provided by that project if it exists. This way the gem is decoupled from user preferences and insulated from Rubocop updates by gem users.

  • 👍7
jakeonrails commented

I'm too tired today to think about implementing this but if you have any suggestions or ideas (or wanna take a crack at it) please let me know. I'll try to look into this over the weekend.

Tolsto commented

Having the .rubocop.yml supplied by the bundling project is a good idea. However, fix-db-schema-conflicts shouldn't use the default config of the bundling project since it is often incompatible with the generated schema.rb file. For example, our Rubocop file has a few rules that schema.rb would violate and that do not have an auto-fix option.

  • 👍2
oboxodo commented

How about to make the rubocop run optional in the first place? In my case I'm interested in the columns sorting but not that much on this gem running rubocop for me. I consider that a separate step.

How difficult do you think it could be to make the rubocop run a separate rake task? Maybe rake db:schema:rubocop?

  • 👍2
jakeonrails commented

@oboxodo Sorry to take so long to reply. The problem with not running Rubocop's autocorrect is that the generated db/schema.rb by Rails often has very weird/obnoxious spacing, which can have the same effect as not having sorted columns when it comes to git diffs. Instead of swapping lines of code back and forth, you'll see the horizontal spacing jump back and forth within the same line. It's been literally years since I've had a raw db/schema.rb (that I haven't used this gem on) so it's hard for me to say if the problem still exists in Rails 5+.

  • 👍1
bengolder commented

We've been using Rails 5 and recently upgraded to Rails 6. We have not seen any issues with horizontal spacing. We found this gem because we were looking for a way to consistently order the lines in schema.rb. For us, it would be helpful to separate the rubocop changes from the schema ordering. We only want a consistent ordering of lines in schema.rb.

  • 👍1