You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm playing around with master at the moment and have come across a case where it is possible for me to run rubocop --auto-gen-config and end up with a configuration that has offences (unless I manually fix things). This is with my .rubocop.yml inheriting from the generated .rubocop_todo.yml, and to date every run of auto-gen-config has then left that project in a state where rubocop is clean, so to not have the happen feels like it's breaking the expected result of auto-gen-config. I'm not sure there's really a need to fix this, or if it'll be possible to do so, but I thought I'd at least raise the issue for awareness or discussion.
My .rubocop.yml contains (this is a common file we share between many projects, to give us a consistent base for checking, which is why it includes cops which still pop up in the local TODO):
Now it seems that, regardless of if inherit_from: .rubocop_todo.yml is above or below the config in the main file, rubocop only sees the Guardfile exclusion and so I get several offences from the files the TODO is trying to exclude. Previously, since the TODO disabled the cop entirely, this did not produce the unexpected behaviour.
I can of course remove the offences this by merging the two configs and placing them in the main or TODO files (neither of which is a great fix) or by fixing all the outstanding problems.
If I understand correctly, your default config is a YAML, which I guess you overwrite with our local file, so having another layer of that with the TODO file and somehow expecting those excludes to merge together (given some people will want replacement instead!) feels like it could get very messy. As said, I'm OK with this not getting fixed, but thought I'd at least draw some attention to it.
The text was updated successfully, but these errors were encountered:
I think it's a bug, and I think it should be fixed. The easiest way is probably to copy any existing Exclude elements to .rubocop_todo.yml when generating it. That should work.
Like you said if I comment out that part in .rubocop.yml and re-generate .rubocop_todo.yml it will be different and copying those values across works but would be better to fix the problem.
I'm playing around with master at the moment and have come across a case where it is possible for me to run
rubocop --auto-gen-config
and end up with a configuration that has offences (unless I manually fix things). This is with my.rubocop.yml
inheriting from the generated.rubocop_todo.yml
, and to date every run of auto-gen-config has then left that project in a state where rubocop is clean, so to not have the happen feels like it's breaking the expected result of auto-gen-config. I'm not sure there's really a need to fix this, or if it'll be possible to do so, but I thought I'd at least raise the issue for awareness or discussion.My
.rubocop.yml
contains (this is a common file we share between many projects, to give us a consistent base for checking, which is why it includes cops which still pop up in the local TODO):While the generated
.rubocop_todo.yml
contains:Now it seems that, regardless of if
inherit_from: .rubocop_todo.yml
is above or below the config in the main file, rubocop only sees the Guardfile exclusion and so I get several offences from the files the TODO is trying to exclude. Previously, since the TODO disabled the cop entirely, this did not produce the unexpected behaviour.I can of course remove the offences this by merging the two configs and placing them in the main or TODO files (neither of which is a great fix) or by fixing all the outstanding problems.
If I understand correctly, your default config is a YAML, which I guess you overwrite with our local file, so having another layer of that with the TODO file and somehow expecting those excludes to merge together (given some people will want replacement instead!) feels like it could get very messy. As said, I'm OK with this not getting fixed, but thought I'd at least draw some attention to it.
The text was updated successfully, but these errors were encountered: