Rename deprecated IgnoredPatterns config to AllowedPatterns
#377
Conversation
|
I think this charge will require bumping the minimum Rubocop version (unless we can configure dynamically based on Rubocop version), and update the test that checks the full config. |
sambostock
force-pushed
the
ignored-to-allowed
branch
from
44b8b74
to
d7112de
Compare
sambostock
force-pushed
the
ignored-to-allowed
branch
from
d7112de
to
c2656e5
Compare
|
🏓 @rafaelfranca & @volmer |
There was a problem hiding this comment.
Thanks for tackling this Sam! I was going to look into this to fix the warnings when bumping Rubocop on Core CI, so it was nice to see you already got to it 😆
I was expecting to have to bump the rubocop version requirement as well -- I'm not aware of a way to handle different configs based on different versions.
|
#380 takes an alternative approach by using ERB to decide between configs by checking the Rubocop version, which allows us to handle the deprecation without forcing consumers to bump their Rubocop version. However, I'm wondering if that matters at all? 🤔 Are we fine with requiring a version bump? |
`IgnoredPatterns` has been renamed to `AllowedPatterns` and deprecated. Switching to the new config requires the new version of Rubocop, and switching to the new version requires using the new config because we forbid deprecations in tests. Therefore, these changes have to happen together.
sambostock
force-pushed
the
ignored-to-allowed
branch
from
c2656e5
to
d8d6793
Compare
|
Could a version bump and release happen? 😅 |
|
I can handle a new release 👍 |
|
Thank you! |
Also bumps Rubocop version.
Closes #376
Caused by rubocop/rubocop#10555
Closes #380
We could also switch to the
!ruby/regexpsyntax for the config, instead of aString, which would remove the need for all the escaping and clarify what the pattern is doing, but I can do that in a different PR.