Open boardfish opened 3 months ago
Thanks for reporting. Do you think we should avoid changing the order of subject definitions and move on?
I think that's one possible option, and is probably the right one – I feel as though we should only avoid doing it if there are multiple subjects in the context, but I don't know how practical it is to suggest that. I've also considered:
subject
was called in the current context and use it to decide how to act here.LeadingSubject
and/or MultipleSubjects
as unsafe for autocorrect.
Given this code:
And this reduced example command (assuming a config that requires
rubocop-rspec
):This autocorrects to:
Output:
I'm guessing the sequence of events is something like this:
RSpec/MultipleSubjects
no-ops. Ordinarily, if executed alone it would turn the namedsubject
into alet
.RSpec/LeadingSubject
moves the named subject to the start of the block.RSpec/LeadingSubject
moves the unnamed subject to the start of the block:MultipleSubjects
removes the unnamedsubject
because it will be overridden by the declaration of thenamed_subject
.This makes the test fail.
This was based on some relatively recent code (albeit a misuse of subjects). I agree with the autocorrect behaviour of
MultipleSubjects
in concept, but I'm not sure what should be done to prevent the conflict of these two cops.