Rails/BulkChangeTable Cop Does Not Function Properly When .rubocop.yml Exists in the db Directory

[ksy90101]

Expected behavior

The Rails/BulkChangeTable cop should function correctly and flag issues in migration files located in the db/migrate directory, even if there is a .rubocop.yml file present in the db directory.

Actual behavior

When a .rubocop.yml file exists in the db directory, the Rails/BulkChangeTable cop does not function as expected. This is because the Include configuration for Rails/BulkChangeTable is set to db/**/*.rb by default, and the presence of .rubocop.yml in the db directory seems to override or disrupt this behavior.

Steps to reproduce the problem
1. Create a Rails project with the following structure:

.
├── .rubocop.yml # Root configuration
├── db/
├── .rubocop.yml # Local configuration in db folder
├── migrate/
├── 20250101_example_migration.rb

2.	Add the following root .rubocop.yml configuration:

Rails/BulkChangeTable:
Enabled: true

3.	Add the following db/.rubocop.yml configuration (even if empty):

db/.rubocop.yml

4.	Create a migration file (db/migrate/20250101_example_migration.rb) with the following content:

class ExampleMigration < ActiveRecord::Migration[6.1]
def change
change_table :users do |t|
t.string :name
t.integer :age
end
end
end

5.	Run RuboCop on the migration file:

rubocop db/migrate/20250101_example_migration.rb

6.	Observe that the Rails/BulkChangeTable cop does not flag any offenses.

Root Cause

The default Include path for Rails/BulkChangeTable is db/**/*.rb. When a .rubocop.yml file exists in the db directory, it seems to override the default behavior and causes the cop to stop functioning for files under the db hierarchy.

Suggested Fix

Modify the Rails/BulkChangeTable cop to handle nested .rubocop.yml files more robustly, ensuring that the presence of a configuration file in the db directory does not interfere with its operation. Alternatively, consider adding a warning or note in the documentation about this potential conflict.

RuboCop version

1.56.3 (using Parser 3.3.6.0, rubocop-ast 1.37.0, running on ruby 3.3.7) [arm64-darwin24]

• rubocop-rails 2.28.0

[Earlopain]

Your RuboCop version is pretty old (1.56 vs latest 1.70). Does this still happen on the latest version?

[ksy90101]

@Earlopain
yes

rubocop -V
1.70.0 (using Parser 3.3.7.0, rubocop-ast 1.37.0, analyzing as Ruby 3.3, running on ruby 3.3.7) +server [arm64-darwin24]
  - rubocop-rails 2.29.0

same bug