False Positive Rubocop RSpec/FilePath Warning

[ghost]

Your environment

• vscode-ruby version: 0.27.0
• Ruby version: 2.7.1
• Ruby version manager (if any): rvm
• VS Code version:1.45.1
• Operating System: macOS Mojave 10.14.6
• Using language server? (eg useLanguageServer is true in your configuration?)
  Tried true and false

Expected behavior

rubocop lint output should match what is run from the command line. There should be no RSpec/FilePath error

Actual behavior

For an rspec file spec/controllers/admin/orders_controller_spec.rb
with the code

describe Admin::OrdersController, type: :controller do
end

I get the following error

{
	"resource": "/Users/alan/Projects/pie-backend/spec/controllers/admin/orders_controller_spec.rb",
	"owner": "rubocop",
	"severity": 2,
	"message": "Spec path should end with `admin/orders_controller*_spec.rb`.",
	"source": "RSpec/FilePath",
	"startLineNumber": 3,
	"startColumn": 1,
	"endLineNumber": 3,
	"endColumn": 52
}

[github-actions]

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

[dcrockwell]

This is still an issue. github-actions should not close an issue as stale without a response from a contributor, lest this be taken as a sign that the project is dead.

[luizkowalski]

I have the exact same issue and it is driving me nuts

[ahukkanen]

This issue still exists, running on VSCode 1.51.1, Ubuntu 20.04, same version of vscode-ruby.

[ahukkanen]

After bit more investigation, the issue might be also in rubocop-rspec.

It's apparently been broken by the rubocop-rspec release 1.39.0 (2020-05-01) which included this change:
rubocop/rubocop-rspec@811ae08#diff-5b709885b35566a0c699ad4a3200b9b7acbc28ef640fa56a8e66f6c732420a34

Here is the related issue I created for this:
rubocop/rubocop-rspec#1091

Maybe they can provide some insight about the issue.

The underlying reason why it does not work in vscode-ruby is also explained in that issue.

[pirj]

Wondering if properly configuring a multi-root workspace helps:

If you are utilizing a monorepo with multiple Gemfiles, it is highly recommended you configure that repository as a multi-root workspace, with each directory owning a Gemfile configured as a workspace folder.

a888116 seems to have added support for falling back to some common root but may have muted the problem with running linters from an incorrect directory.

[cirdes]

same here, any updates?

[droarty]

same, a year later.

[amicojeko]

Wondering if properly configuring a multi-root workspace helps:

If you are utilizing a monorepo with multiple Gemfiles, it is highly recommended you configure that repository as a multi-root workspace, with each directory owning a Gemfile configured as a workspace folder.

a888116 seems to have added support for falling back to some common root but may have muted the problem with running linters from an incorrect directory.

It didn't for me :(