Enable RSpec/LeakyConstantDeclaration cop
Description of the proposal
This enables RSpec/LeakyConstantDeclaration
cop while ignoring all current violations. This was disabled in the upgrade to gitlab-styles
3.1.0. See !21886 (merged).
From https://www.rubydoc.info/gems/rubocop-rspec/RuboCop/Cop/RSpec/LeakyConstantDeclaration
Checks that no class, module, or constant is declared.
Constants, including classes and modules, when declared in a block scope, are defined in global namespace, and leak between examples.
If several examples may define a
DummyClass
, instead of being a blank slate class as it will be in the first example, subsequent examples will be reopening it and modifying its behaviour in unpredictable ways. Even worse when a class that exists in the codebase is reopened.Anonymous classes are fine, since they don't result in global namespace name clashes.
# bad
describe SomeClass do
OtherClass = Struct.new
CONSTANT_HERE = 'I leak into global namespace'
end
# good
describe SomeClass do
before do
stub_const('OtherClass', Struct.new)
stub_const('CONSTANT_HERE', 'I only exist during this example')
end
end
Current Violations
15217 files inspected, 158 offenses detected
Please vote
Check-list
-
Make sure this MR enables a static analysis check rule for new usage but ignores current offenses -
Create a follow-up issue to fix the current offenses as a separate iteration: #211580 -
Mention this proposal in the relevant Slack channels (e.g. #development
,#backend
,#frontend
) -
If there is a choice to make between two potential styles, set up an emoji vote in the MR:CHOICE_A:🅰 CHOICE_B:🅱 Vote yourself for both choices so that people know these are the choices
-
The MR doesn't have significant objections, and is getting a majority of 👍 vs👎 (remember that we don't need to reach a consensus) -
(If applicable) One style is getting a majority of vote (compared to the other choice) -
(If applicable) Update the MR with the chosen style -
Follow the review process as usual -
Once approved and merged by a maintainer, mention it again: -
In the relevant Slack channels (e.g. #development
,#backend
,#frontend
) -
(Optional depending on the impact of the change) In the Engineering Week in Review
-