Style/ClosingParenthesisIndentation has the wrong namespace - should be Layout

[stuartweir]

Hi there, I need help with an issue I'm having with VS Code rubocop integration that never used to show up. I'm getting a pop up on every single Ruby file that says Style/ClosingParenthesisIndentation has the wrong namespace - should be Layout, so I update the .rubocop.yml file to Layout, and then I get Layout/ClosingParenthesisIndentation has the wrong namespace - should be Style. As you could imagine, this is very frustrating. How can I fix this?

[damien]

Hey @stuartweir! Are you getting both of these warnings within VSCode, or are you seeing your command line rubocop disagreeing with what rubocop within VSCode is telling you?

I've seen this happen to me when I have differing versions of rubocop reading a configuration that works for one, but not the other. Let me know what you see!

[aried3r]

Rubocop 0.49 moved the cops to a different layout. In the terminal everything works as expected.

How do I find out which rubocop this extension is using? I have no settings regarding ruby.rubocop.executePath but it's looking for Rubocop in Ruby 2.3.1 (while I use 2.4.1 in this project, using rbenv).

[damien]

As I understand it, ruby.rubocop.executePath is the directory the VSCode extension searches for the rubocop executable. Failing that, it'll just look for the rubocop executable in $PATH.

I don't think this extension has any awareness of which ruby it uses to execute. I'm not sure if that's an oversight, f it's by design, or if it's a limitation in the current version of VSCode—@misogi may know.

[stuartweir]

Is the execute path the .rubocop.yml file in my project? or somewhere else? because I have multiple projects taht use rubocop, and dont want to change that all the time. But to confirm, rubocop doesnt complain doing bundle exec rubocop <file> on the CLI, but only in VS Code

[damien]

It'll be whatever directory your rubycop executable lives in. If you haven't set it explicitly in Rubocop, I believe VSCode will just search your $PATH to figure out how to invoke it.

There's ongoing work to make this extension smarter about how it finds/invokes rubocop, but if the current state of things is breaking things for you, expliciting setting the executePath can help—I think I currently have mine set to something like /usr/local/var/rbenv/shims.

[JStans12]

I'm seeing a similar error

.../.rubocop.yml: Style/AccessModifierIndentation has the wrong namespace - should be Layout

My rubocop config works fine in atom.

[christiandennis]

same issue here

Style/SpaceInsideHashLiteralBraces has the wrong namespace - should be Layout

[jaylee185]

https://github.com/bbatsov/rubocop/blob/master/manual/cops.md#layout Here can find the cop deparments. The only issue I have is Naming/PredicateName got marked as in Style.

[dneilroth]

I am also seeing Layout/DotPosition has the wrong namespace - should be Style in VScode 1.18.1. I have "ruby.rubocop.executePath" pointed at the binary in my rvm ruby version 2.4.1. Changing to a binary in an older version of Ruby doesn't seem to fix it and it works fine in Atom.

I do have "ruby.rubocop.configFilePath" pointed to a yml file in another repo.

EDIT: I noticed that my repos that are using ruby 2.4.1 did not have this issue so I pointed the configFilePath at the lowest ruby version I am running and it seems to have resolved the issue.

[Hbbb]

I have this issue as well, both on the CLI as well as in VSCode. Currently, this extension treats any warnings from Rubocop as errors, and terminates the run. On the CLI, Rubocop will warn you of incorrect namespaces but it will still lint the file. Can we update this extension to have the same behavior? I'd argue that this extension should ignore warnings and continue to lint unless there is an actual error running Rubocop.

[yusefu]

To fix it just replace in your .rubocop.yml file Style by Layout.

# change this
Style/ClosingParenthesisIndentation
# to this
Layout/ClosingParenthesisIndentation

[Hbbb]

@yusefu You're correct, that does solve the issue. What I was calling attention to is the fact that the Rubocop binary still lints the file despite these warnings. I was hoping to see the same behavior implemented in this extension. I'm happy to help contribute 😀

[CharlieIGG]

@yusefu You're correct, that does solve the issue. What I was calling attention to is the fact that the Rubocop binary still lints the file despite these warnings. I was hoping to see the same behavior implemented in this extension. I'm happy to help contribute 😀

+1