Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rails/EnumSyntax fails to detect non-literal mapping Hashes #1343

Closed
wenley opened this issue Aug 26, 2024 · 0 comments · Fixed by #1348
Closed

Rails/EnumSyntax fails to detect non-literal mapping Hashes #1343

wenley opened this issue Aug 26, 2024 · 0 comments · Fixed by #1348
Labels
bug Something isn't working

Comments

@wenley
Copy link

wenley commented Aug 26, 2024

The recently-introduced Rails/EnumSyntax cop successfully works with literal mapping Hashes. e.g.

enum(column_name: { "a" => "a", "b" => "b" })

However, it fails to detect non-literal mapping Hashes, e.g.

VALUES = ["a", "b"]
enum(column_name: VALUES.zip(VALUES).to_h)

Expected behavior

The second example above should be flagged as a violation, and should be auto-corrected to:

enum(:column_name, VALUES.zip(VALUES).to_h)

Actual behavior

The example is not detected as an issue.

Steps to reproduce the problem

Add the following lines to a model file and see the difference in reported violations when running bundle exec rubocop

  # Correctly gets flagged
  enum(column_one: { "a" => "a", "b" => "b" })

  # Incorrectly does not get flagged
  VALUES = ["a", "b"]
  enum(column_two: VALUES.zip(VALUES).to_h)

RuboCop version

$ bundle exec rubocop -V
1.65.1 (using Parser 3.3.4.2, rubocop-ast 1.32.1, running on ruby 3.3.1) [arm64-darwin23]
  - rubocop-capybara 2.21.0
  - rubocop-factory_bot 2.26.1
  - rubocop-performance 1.21.1
  - rubocop-rails 2.26.0
  - rubocop-rake 0.6.0
  - rubocop-rspec 3.0.4
@koic koic added the bug Something isn't working label Aug 26, 2024
Earlopain added a commit to Earlopain/rubocop-rails that referenced this issue Sep 1, 2024
I don't believe there is any issue with just looking at all value types.
It just translates `foo: bar` into `:foo, bar`.
Earlopain added a commit to Earlopain/rubocop-rails that referenced this issue Sep 1, 2024
I don't believe there is any issue with just looking at all value types.
It just translates `foo: bar` into `:foo, bar`.
Earlopain added a commit to Earlopain/rubocop-rails that referenced this issue Sep 1, 2024
I don't believe there is any issue with just looking at all value types.
It just translates `foo: bar` into `:foo, bar`.
Earlopain added a commit to Earlopain/rubocop-rails that referenced this issue Sep 1, 2024
I don't believe there is any issue with just looking at all value types.
It just translates `foo: bar` into `:foo, bar`.
Earlopain added a commit to Earlopain/rubocop-rails that referenced this issue Sep 3, 2024
I don't believe there is any issue with just looking at all value types.
It just translates `foo: bar` into `:foo, bar`.

Additionally, add `instance_methods` as a rails option. Not doing this would
result autocorrect treating it as a enum column
@koic koic closed this as completed in #1348 Sep 3, 2024
koic added a commit that referenced this issue Sep 3, 2024
[Fix #1343] False negatives for `Rails/EnumSyntax`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants
@koic @wenley and others