In editor a linting (rubocop) error is show that doesn't appear in console

[shir]

Your environment

• vscode-ruby version: 0.28.1
• Ruby version: 2.7.2
• Ruby version manager (if any): asdf 0.8.0
• VS Code version: 1.52.1
• Operating System: Mac OS X 11.1
• Using language server? (eg useLanguageServer is true in your configuration?): Yes
• Rubocop version: 1.7.0

Expected behavior

I expect that I don't see any rubocop error in the editor I there is no errors when I run rubocop from the console.

Actual behavior

I see the next error in the editor:

But when I run rubocop in console for this file I don't see any error (and shouldn't):

❯ rubocop app/models/article.rb
Inspecting 1 file
.

1 file inspected, no offenses detected

If I try to run rubocop as language server do I don't have errors too:

❯ cat /Users/shir/project/app/models/article.rb | rubocop -s '/Users/shir/project/app/models/article.rb' -f json
{"metadata":{"rubocop_version":"1.7.0","ruby_engine":"ruby","ruby_version":"2.7.2","ruby_patchlevel":"137","ruby_platform":"x86_64-darwin19"},"files":[{"path":"app/models/article.rb","offenses":[]}],"summary":{"offense_count":0,"target_file_count":1,"inspected_file_count":1}}%

If I remove this # rubocop:disable Rails/EnumHash comment then the error in the editor disappear, but I will have an error when I run rubocop from the console:

❯ rubocop app/models/article.rb
Inspecting 1 file
C

Offenses:

app/models/article.rb:37:16: C: [Correctable] Rails/EnumHash: Enum defined as an array found in status enum declaration. Use hash syntax instead.
  enum status: [:published, :draft]
               ^^^^^^^^^^^^^^^^^^^^

1 file inspected, 1 offense detected, 1 offense auto-correctable

I'm not sure when this error appears after rubocop update or after the last vscode-ruby update.

I will be glad to help with any debugging but right now I don't know where to go.

[shunichi]

I have the same problem.
It seems to occur because of executing linter in the target source file directory.
rubocop must be executed in the project root directory.

This commit seems to break rubocop linter.
c1b87d3

rubocop's Include and Exclude paths are based on current working directory.

The default config of Rails/EnumHash includes app/models/**/*.rb.
vscode-ruby executes rubocop in app/models and the include path pattern is expanded to $(PROJECT_DIR)/app/models/app/models/**/*.rb. So Rails/EnumHash is not enabled for $(PROJECT_DIR)/app/models/article.rb

Rails/EnumHash:
  Description: 'Prefer hash syntax over array syntax when defining enums.'
  StyleGuide: 'https://rails.rubystyle.guide#enums'
  Enabled: true
  VersionAdded: '2.3'
  Include:
    - app/models/**/*.rb

https://github.com/rubocop-hq/rubocop-rails/blob/0e99ca4d710640dd46a47c7c3fbd1186e17e3f82/config/default.yml#L220-L226

[shunichi]

Using solargraph is a workaround.

Install solargraph 0.40.0.
0.40.1 <= has a bug.
castwide/solargraph#401

Configure vscode like this.

  // linter config
  "ruby.lint": {
  	"rubocop": false,
  },
  "solargraph.useBundler": true, // true if solargraph is in Gemfile
  "solargraph.diagnostics": true,

  // formatter config
  "ruby.format": false,  
  "solargraph.formatting": true,
  "[ruby]": {
    "editor.defaultFormatter": "castwide.solargraph",
    "editor.formatOnSave": true,
  },

And place .rubocop in your project directory like this, or rubocop's Exclude settings are ignored.

--force-exclusion

See castwide/vscode-solargraph#155

[wolfgangrittner]

Another workaround is to install version 0.27.0 of vscode-ruby instead of latest 0.28.1 which causes the issue outlined above.

[shir]

I confirm that the issue doesn't appear on 0.27.0.

[shir]

And I have this issue to appear only for rules that have exclusion for some file. If a file is excluded from a rule, then I see a warning for this rule in VSCode but don't see it when run rubocop from the console.

[github-actions]

This issue has not had activity for 30 days. It will be automatically closed in 7 days.

[shir]

it's active

[AndreiEres]

It's very annoying of course. How can I configure vscode to behave exactly like in console using .rubocop.yml?

[github-actions]

This issue has not had activity for 30 days. It will be automatically closed in 7 days.

[simonc]

It's active 😊

[AndreiEres]

Any updates? :-)

[github-actions]

This issue has not had activity for 30 days. It will be automatically closed in 7 days.

[shir]

It's active. Stupid bot.

[simonc]

Anything we can do to help fix/release this? 🙂

[github-actions]

This issue has not had activity for 30 days. It will be automatically closed in 7 days.

[shir]

Development for this project is too slow to use this bot. No new releases for half a year.

[github-actions]

This issue has not had activity for 30 days. It will be automatically closed in 7 days.

[simonc]

Naaaah you stupid bot. It's active!

[AndreiEres]

I think the problem is not in the bot :-)

[simonc]

I know. Seriously I'd be open to being a bit more involved in the project to help it move forward. Ruby is far from a dying language and it's killing me that this extension doesn't get updated more often.

Dear maintainer(s), would you consider bringing more people to the table?

[wingrunr21]

Yes

Just know that the support load from this extension is high. You have to be able to troubleshoot peoples environments to fix issues. The permutations of Rubies, version managers, Gemfiles, expectations, etc is tough.

Plus, keeping up with the pace of VSCodes development for free, in your spare time, is pretty rough. People complain about the debugger a lot and I can count on one hand the number of PRs I get on it.

Just being honest here. I don’t look at this much anymore due to A) not coding much anymore and B) burnout

[simonc]

Thanks for the disclaimer @wingrunr21. I appreciate the work you've done to make this extension. I think the more people on board the lighter each individual contribution can be. But I'm not naive, I know people want things to be done for them, not by them, most of the time.

I haven't had much spare time lately, working on two jobs + 1 baby 😅, but if I can be of help, I'd like to.

Given how many companies use Ruby as their main language and how many developers are using VSCode today, did any of them approached you to propose some help? Maybe I could try to reach out to some of them if it's not the case 🙂 if it's something that you would consider of course.

[wingrunr21]

I have not had anyone approach me, no.

I will set aside time this weekend to review open (and probably closed by the bot) PRs and get things up to date. I'll also be adding a call for maintainers to the README. Perhaps with Hacktoberfest coming up we can clean up the issues list and get some folks to contribute.

[simonc]

That'd be awesome 🙂 Once again, thanks for the time you're putting in.

[github-actions]

This issue has not had activity for 30 days. It will be automatically closed in 7 days.

[simonc]

🤖🔫

[github-actions]

This issue has not had activity for 30 days. It will be automatically closed in 7 days.

[shir]

active

[wolfgangrittner]

I might be able to add some details, maybe this helps someone more familiar with the inner workings of this extension to know what to look for:

If you've got something like this in your .rubocop.yml

Metrics/BlockLength:
  Exclude:
    - lib/tasks/**/*.rake

long Blocks in rake tasks will be highlighted in vs code, while rubocop run from command line will tell you everything is fine.

If you changed your configuration to one of the below, exclusions will work fine in vs code, no more false positives:

Metrics/BlockLength:
  Exclude:
    - lib/tasks/**/*

or

Metrics/BlockLength:
  Exclude:
    - lib/tasks/**/*.rake*

or

Metrics/BlockLength:
  Exclude:
    - lib/tasks/**/*.rake'

=> It seems like for some reason rubocop is taking the file name it is given by the extension too literally, including the quotes around the file name when matching exclusions.
Now when the extensions invokes rubocop by running rubocop -s '/Users/me/project/lib/tasks/sometask.rake' -f json it seems like it includes the trailing quote on the filename there, and lib/tasks/sometask.rake' just doesn't match lib/tasks/**/*.rake.
This is weird, and I can't reproduc it on a shell, running that same command manually.

Update:
ha, that's also why downgrading to version 0.27.0 works, because that one runs rubocop -s /Users/me/project/lib/tasks/sometask.rake -f json (without the single quotes around the file name).

[benzado]

I think this is another duplicate of #719 and was fixed on main by PR #720.

[github-actions]

This issue has not had activity for 30 days. It will be automatically closed in 30 days.

[shir]

It's still active. Maybe it will be fixed in the next release because potential PR was merged.

[github-actions]

This issue has not had activity for 30 days. It will be automatically closed in 30 days.

[simonc]

🤖

[github-actions]

This issue has not had activity for 30 days. It will be automatically closed in 30 days.

[shir]

🤖