Do not accept abbreviated options for cli #12282
Conversation
|
Today I learned. 😆 I agree that's more of a bug, as I never meant for this to be the actual behavior. |
|
Um, this change could potentially be a breaking change for some users. Whether the shorthand name is appropriate or not may be a matter of perspective. |
I also thought of this, but I can't think of a single time I've seen someone use those shorthand options (in any application), so I don't think that's a big deal. Normally they are useful for commands that don't have a shorthand in the first place, but I think it RuboCop pretty much every command has an explicit shorthand. |
| @@ -0,0 +1 @@ | |||
| * [#12280](https://github.com/rubocop/rubocop/issues/12280): Do not accept abbreviated options for cli. ([@fatkodima][]) | |||
There was a problem hiding this comment.
| * [#12280](https://github.com/rubocop/rubocop/issues/12280): Do not accept abbreviated options for cli. ([@fatkodima][]) | |
| * [#12280](https://github.com/rubocop/rubocop/issues/12280): **(Breaking)** Do not accept abbreviated options for cli. ([@fatkodima][]) |
If this change is made, it seems prudent to explicitly note **(Breaking)** in the changelog entry.
|
We can also simply bucket this to the list of breaking changes liked up for a potential RuboCop 2.0 down the road. |
|
Ah, might be overthinking on my part. Releasing it without waiting for RuboCop 2.0 could probably be tried. (e.g. next minor release) |
|
Agreed with both of you. Do not think anyone uses it. CI is broken, because seems like I have found a bug in |
Fixes #12280.
Was also surprised that rubocop's cli accepts abbreviated options. I do not think this is a convenience, but more like a bug if you do not specify the correct option.