Stateless Code | Change RuboCop Config to Enable New Cops By Default for a Rails Application @StatelessCode | Uploaded January 2023 | Updated October 2024, 2 hours ago.
Right now our app does not have new RuboCop cops enabled by default. Because of this, every time we update the bundle to a new version of RuboCop, we need to take all the new cops printed in the warning and paste them into our rubocop.yml file.
This makes the rubocop.yml file longer and forces it to contain a bunch of configuration that we really don't care about. An alternative to this approach is to enable new cops by default. If we change the configuration to do this, it will result in a much shorter configuration file with only the configuration that matters in the rubocop.yml file.
There is a trade-off though. Whenever we run a bundle update now, it may cause build-breaking changes to our code base. In those cases, we would need to evaluate the new failures. When we see new failures, we can either modify the code base to conform to the new standard or exclude the cop in our configuration file.
I'm willing to make that trade though, as I believe it results in a configuration environment that is easier to read and maintain.
We go through and prune out all the redundant cops and then run the rubocop command to show that they now appear in the list of warnings as expected. After that, we enable the new cops and see what happens.
It turns out that we accidentally deleted configuration that disables a default cop. We add that back in and complete the story. We like it so much that we add a similar item to the backlog of our NerdDice RubyGem project.
This video covers:
00:00:12 Introduction, overview of current state, and plan for the video
00:02:22 Run rubocop --debug to get more detail about what is currently happening
00:02:48 Add the tmp directory of the project to the set of directories to exclude
00:04:28 Change TargetRubyVersion to 3.2
00:04:49 Clear out the new in version x.xx lines from the rubocop.yml file
00:07:20 Review version of rubocop.yml after removing the new cops and compare against footprint of previous version of file
00:08:21 Re-run without yet enabling new cops to see the increase in warnings
00:08:55 Enable new cops by default and re-run
00:09:49 Disable the Minitest/MultipleAssertions cop which was accidentally removed from the config
00:11:35 Discussion of how to proceed in future `bundle update` situations
00:12:12 Highlight RuboCop.org and the command line documentation
00:14:43 Commit and push the code
00:15:48 Add a similar RuboCop backlog item for the NerdDice RubyGem
00:17:00 Pull request, merge, and close the issue
#ruby #rails7 #rails #rubyonrails #rubygems #codecast #screencast #github #opensource #minitest #TDD #agile #NerdDice #DnD #roleplaying #softwaredevelopment #learntocode #rubocop
See other related StatelessCode videos:
- Codecast: Rubocop install and initial setup youtu.be/dKpiJhA19yg
- Codecast: Create a RubyGem 03: Set up RuboCop and flesh out the README youtu.be/Iz_Wl-IDL-c
- Codecast: Create a RubyGem 09: Fix RuboCop issues and release a patch version youtu.be/2tw6ozMgTpQ
- Codecast: Create a RubyGem 27: Add Rubocop to Github Actions youtu.be/2tw6ozMgTpQ
- Update Ruby then Add RuboCop to a Rails Project youtu.be/5MbY5k5Wk68
Resources that we relied upon for this solution:
- RuboCop main site rubocop.org
- RuboCop Documentation for command line docs.rubocop.org/rubocop/usage/basic_usage.html
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.
Right now our app does not have new RuboCop cops enabled by default. Because of this, every time we update the bundle to a new version of RuboCop, we need to take all the new cops printed in the warning and paste them into our rubocop.yml file.
This makes the rubocop.yml file longer and forces it to contain a bunch of configuration that we really don't care about. An alternative to this approach is to enable new cops by default. If we change the configuration to do this, it will result in a much shorter configuration file with only the configuration that matters in the rubocop.yml file.
There is a trade-off though. Whenever we run a bundle update now, it may cause build-breaking changes to our code base. In those cases, we would need to evaluate the new failures. When we see new failures, we can either modify the code base to conform to the new standard or exclude the cop in our configuration file.
I'm willing to make that trade though, as I believe it results in a configuration environment that is easier to read and maintain.
We go through and prune out all the redundant cops and then run the rubocop command to show that they now appear in the list of warnings as expected. After that, we enable the new cops and see what happens.
It turns out that we accidentally deleted configuration that disables a default cop. We add that back in and complete the story. We like it so much that we add a similar item to the backlog of our NerdDice RubyGem project.
This video covers:
00:00:12 Introduction, overview of current state, and plan for the video
00:02:22 Run rubocop --debug to get more detail about what is currently happening
00:02:48 Add the tmp directory of the project to the set of directories to exclude
00:04:28 Change TargetRubyVersion to 3.2
00:04:49 Clear out the new in version x.xx lines from the rubocop.yml file
00:07:20 Review version of rubocop.yml after removing the new cops and compare against footprint of previous version of file
00:08:21 Re-run without yet enabling new cops to see the increase in warnings
00:08:55 Enable new cops by default and re-run
00:09:49 Disable the Minitest/MultipleAssertions cop which was accidentally removed from the config
00:11:35 Discussion of how to proceed in future `bundle update` situations
00:12:12 Highlight RuboCop.org and the command line documentation
00:14:43 Commit and push the code
00:15:48 Add a similar RuboCop backlog item for the NerdDice RubyGem
00:17:00 Pull request, merge, and close the issue
#ruby #rails7 #rails #rubyonrails #rubygems #codecast #screencast #github #opensource #minitest #TDD #agile #NerdDice #DnD #roleplaying #softwaredevelopment #learntocode #rubocop
See other related StatelessCode videos:
- Codecast: Rubocop install and initial setup youtu.be/dKpiJhA19yg
- Codecast: Create a RubyGem 03: Set up RuboCop and flesh out the README youtu.be/Iz_Wl-IDL-c
- Codecast: Create a RubyGem 09: Fix RuboCop issues and release a patch version youtu.be/2tw6ozMgTpQ
- Codecast: Create a RubyGem 27: Add Rubocop to Github Actions youtu.be/2tw6ozMgTpQ
- Update Ruby then Add RuboCop to a Rails Project youtu.be/5MbY5k5Wk68
Resources that we relied upon for this solution:
- RuboCop main site rubocop.org
- RuboCop Documentation for command line docs.rubocop.org/rubocop/usage/basic_usage.html
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.
