Add configuration option CustomTransformPatterns to RSpec/SpecFilePathFormat

[ydah]

Motivation

For example, if you have the following files:

# rspec_foo_spec.rb
RSpec.describe RSpecFoo do
end

# rspec_bar_spec.rb
RSpec.describe RSpecBar do
end

# rspec_baz_spec.rb
RSpec.describe RSpecBaz do
end

Suppose you have the following .rubocop.yml:

RSpec/SpecFilePathFormat:
  CustomTransform:
    RSpec: rspec

But this would be offense:

❯ bundle exec rubocop rspec* --only RSpec/SpecFilePathFormat
Inspecting 3 files
CCC

Offenses:

rspec_bar_spec.rb:1:1: C: RSpec/SpecFilePathFormat: Spec path should end with r_spec_bar*_spec.rb.
RSpec.describe RSpecBar do

rspec_baz_spec.rb:1:1: C: RSpec/SpecFilePathFormat: Spec path should end with r_spec_baz*_spec.rb.
RSpec.describe RSpecBaz do

rspec_foo_spec.rb:1:1: C: RSpec/SpecFilePathFormat: Spec path should end with r_spec_foo*_spec.rb.
RSpec.describe RSpecFoo do


3 files inspected, 3 offenses detected

So how about something that can be specified in a pattern?

---

Before submitting the PR make sure the following are checked:

• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Updated documentation.
• Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
• The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

If you have modified an existing cop's configuration options:

• Set VersionChanged: "<<next>>" in config/default.yml.

[pirj]

Wr had this option in FilePath? How comes we’ve missed copying it over to this cop whennsplitting ?
What about yhe other cop, does it need the option?
There is no way to declare this in the obsoletion conf, is there?

Thank you!

[ydah]

@pirj We didn't have this option in FilePath and had the same issue 👍🏻

❯ bundle exec rubocop rspec* --only RSpec/FilePath          
Inspecting 3 files
CCC

Offenses:

rspec_bar_spec.rb:1:1: C: RSpec/FilePath: Spec path should end with r_spec_bar*_spec.rb.
RSpec.describe RSpecBar do
^^^^^^^^^^^^^^^^^^^^^^^
rspec_baz_spec.rb:1:1: C: RSpec/FilePath: Spec path should end with r_spec_baz*_spec.rb.
RSpec.describe RSpecBaz do
^^^^^^^^^^^^^^^^^^^^^^^
rspec_foo_spec.rb:1:1: C: RSpec/FilePath: Spec path should end with r_spec_foo*_spec.rb.
RSpec.describe RSpecFoo do
^^^^^^^^^^^^^^^^^^^^^^^

3 files inspected, 3 offenses detected

[pirj]

We probably had the same issue because ‘rspec’ was not in the defaults?
I see this option in the docs https://docs.rubocop.org/rubocop-rspec/cops_rspec.html#rspecfilepath

[ydah]

This is occurring though RSpec: rspec is set by default.
https://docs.rubocop.org/rubocop-rspec/cops_rspec.html#configurable-attributes-16

It also occurs when explicitly specified as follows

RSpec/FilePath:.
  Enabled: true
  CustomTransform: true
    RSpec: rspec

[pirj]

That is weird. Wondering, why?
We even have a spec for that

rubocop-rspec/spec/rubocop/cop/rspec/file_path_spec.rb

Line 288 in b99bf78

let(:cop_config) { { 'CustomTransform' => { 'FooFoo' => 'foofoo' } } }

Is there a guarantee that specs from this PR won’t conceal the problem ?

[ydah]

This test does not guarantee this case.
The following cases can be guaranteed

# foofoo/some/class/bar_spec.rb
describe FooFoo::Some::Class, '#bar' do; end

Note, however, that the following cases of foofoo_bar and bar_foofoo are not guaranteed.

# foofoo_bar/some/class/bar_spec.rb
describe FooFooBar::Some::Class, '#bar' do; end

Because CustomTransform only works if the implementation is also an exact match.

rubocop-rspec/lib/rubocop/cop/rspec/file_path.rb

Line 131 in b99bf78

custom_transform.fetch(name) { camel_to_snake_case(name) }

[pirj]

A-ha!
Please accept my sincere apologies, I misunderstood the whole thing 🙈

So this is an additional option.
Wondering if we could just treat existing transforms as patterns?

[ydah]

So this is an additional option. Wondering if we could just treat existing transforms as patterns?

I'm wondering if adding this feature as a separate additional option might be better in order to ensure backward compatibility when there are already custom settings in CustomTransform. What do you think?

[pirj]

What i meant with reusing the option was to allow ‘“RSpec” => “rspec”’ config in CustomTransform.
That would still be backwards-compatible.
I’m not against the new option, but I experience some cognitive resistance due to the lack of real examples.
Would the following make good examples of partial trasgormations?
API -> api
DSL -> dsl

[pirj]

I’m still not convinced with RSpecClass.

[ydah]

Sorry for the delay. I have updated this PR. How do you like it?

[pirj]

I’m still not convinced with RSpecClass.

[ydah]

I updated this PR.

[pirj]

The best way to demo the difference between those two option would be RSpec.describe CustomDSL and DSL => dsl mapping. One would insist on custom_d_s_l_*spec.rb, the other on custom_dsl_*spec.rb, right?

Namespaces and RSpecFoo don't help understand it.

I keep losing grip about this option.

[ydah]

This does not appear to be an offense when followed by only one uppercase letter, as in DSL, so this is not the case that can be resolved with this option. This option may not be a common use case.

[pirj]

Please pardon my continuous inability to understand what problem this PR solves.
Is it some capitalized words with untypical conversion to snake case like DBase, RSpec, VSync, macOS that are used as part of multiple classes (and specs for them)? Like MacOSFileSystem MacOSKeyChain etc?
Is it widespread? How does e.g Zeitwerk deal with classes themselves?

[ydah]

Is it some capitalized words with untypical conversion to snake case like DBase, RSpec, VSync, macOS that are used as part of multiple classes (and specs for them)? Like MacOSFileSystem MacOSKeyChain etc?

Yes
For example, if you are implementing a custom cop in a Rails application and the cop is a cop related to RSpec, you might create classes for cop called RSpecFoo and RSpecBar.
Of course, creating a department might solve the problem, but in many cases there are not that many custom cops created, so you might put files under lib/rubocop/cop/project_name.
At that time, setting CustomTransform for each file was troublesome.

For example, the following custom cup collection does not have separate divisions, so CustomTransform needs to set them up one by one.
https://github.com/ydah/workitcop/tree/main/lib/rubocop/cop/workit

I'm not sure this is common, though.

[bquorning]

I’ll try to argue that CustomTransform solves this problem already. Yes, in a few cases it will require a long list, but at least that long list will be easy to understand. I find CustomTransformPatterns more difficult to understand.

[ydah]

I find CustomTransformPatterns more difficult to understand.

That may indeed be true. Thank you. I will close this PR.