-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Open
Labels
Description
Whenever including constants in a custom category, Rubocop is unable to flag any incorrect constant ordering. An example can be seen below.
This configuration:
Layout/ClassStructure:
Enabled: true
Categories:
constants_and_props:
- prop
- constants
associations:
- belongs_to
- has_one
- has_many
- has_and_belongs_to_many
- has_one_attached
- has_many_attached
- has_rich_text
...
ExpectedOrder:
- constants_and_props
- associations
...
Will not flag the constant in this example with an invalid layout:
# frozen_string_literal: true
class Example
include Literal::Properties
attribute :foo
prop :bar, String # RuboCop[Layout/ClassStructure] offense raised
SOME_CONSTANT = "constant" # NO OFFENSE RAISED (ISSUE)
end
Our questions are the following:
- Is this an expected behavior? Is there a different namespace to reference constants that we should utilize?
- If not, what can we do to ensure that constants get flagged under parent categories?
Steps to reproduce the problem
- Update the
.rubocop.ymlfile to includeconstantsunder a different parent category. - Create a violation in any class
- Note if the constant layout is flagged
Expected behavior
I expect a Layout/ClassStructure offense where the constants parent class is supposed to appear before any classes listed after the parent.
Actual behavior
No offenses are brought up
RuboCop version
$ bundle exec rubocop -V
1.81.7 (using Parser 3.3.10.0, Prism 1.6.0, rubocop-ast 1.48.0, analyzing as Ruby 3.4, running on ruby 3.4.4) [arm64-darwin24]
- standard-custom 1.0.2
- standard-performance 1.8.0
- rubocop-capybara 2.22.1
- rubocop-factory_bot 2.28.0
- rubocop-performance 1.25.0
- rubocop-rspec_rails 2.32.0
- rubocop-rails 2.34.2
- rubocop-rspec 3.8.0