rubocop not using .rubocop.yml file

[Zhorian]

Your environment

• vscode-ruby version: 0.26.0
• Ruby version: 2.6.3p62
• Ruby version manager (if any): 1.29.9
• VS Code version: 1.41.1
• Operating System: Linux Mint 19.3
• Using language server? (eg useLanguageServer is true?) true

Expected behavior

I'm expecting test/test_helper.rb to be ignored by rubocop based on my .rubocop.yml file. Confirmed config file is being used when running rubocop from the command line.

Actual behavior

I am still receiving linting errors on the for test/test_helper.rb

This and the next section should include screenshots, code samples, console output, etc. The more information we have to reproduce the better!

settings.json
{ "editor.formatOnSave": true, "editor.formatOnSaveTimeout": 5000, "powermode.enabled": true, "powermode.enableShake": false, "ruby.useLanguageServer": true, "ruby.lint": { "rubocop": true }, "ruby.format": "rubocop", "sync.gist": "d1b8c7400637948e668f4c6d174c5edb", "workbench.colorTheme": "Blueberry Banana", "workbench.iconTheme": "vscode-icons", }

.rubocop.yml
AllCops: TargetRubyVersion: 2.6.3 Exclude: - "**/*.erb" - db/schema.rb - "bin/**/*" - "node_modules/**/*" - test/test_helper.rb - test/channels/application_cable/connection_test.rb

[Zhorian]

Interestingly this seems to occur when using Solargraph diagnostics too!

[andrewmcodes]

Try turning the bundler option on. I’m not sure if the gem will automatically find the config file in your directory instead of looking globally.

https://github.com/rubyide/vscode-ruby/blob/master/docs/linting.md#configuration-options

[Zhorian]

I've updated my ruby lint settings to below and the issue persists.

"ruby.lint": { "rubocop": { "command": "rubocop", "useBundler": true, } },

[artm]

"useBundler": true is ignored when "command" is given.

[artm]

Context

I had a similar problem but in a somewhat convoluted environment, which I was able to investigate and solve, but my solution is convoluted as well :-) Perhaps @Zhorian's situation is similar in some respect?

My VSCode runs on a windows host connecting via remote ssh extension to a linux developmen VM inside which ruby environments are run in docker containers with docker-compose, so VSCode doesn't have direct access to any ruby commands.

Solving the problem in my context

In order to help linter execute rubocop inside my environment I made a project specific wrapper script inside the project's bin directory and corresponding linter config:

    "ruby.lint": {
        "rubocop": {
            "command": "bin/vscode-rubocop"
        }
    },

My first attempt suffered from this issue (rubocop not respecting .rubocop.yml:

#!/bin/bash
docker-compose exec -T application rubocop "$@"

This happens because of the way linter calls the script (according to the output in the Output view:

Lint: executing bin/vscode-rubocop -s /home/artm/src/project/app/controllers/application_controller.rb -f json

current contents of the file is sent on the stdin (rubocop's -s option) along with the absolute path to the file on the VM's filesystem. But since rubocop is running in a container the same file is available under a different absolute path (/app/app/controllers/application_controller.rb which corresponds to the same relative path because the project directory is mounted to /app. So I adjusted the wrapper script to strip current path prefix from every argument:

#!/bin/bash
docker-compose exec -T application rubocop "${@#$(pwd)/}"

This made rubocop respect .rubocop.yml because now it knows the file path and can find the corresponding configuration file(s).

Suggestions for the extension config

• pass source paths relative to the project root
• run 'command' + args via shell instead of assuming it's a name of executable, so we could configure something like:

    "ruby.lint": {
        "rubocop": {
            "command": "docker-compose exec -T spring spring rubocop",
            "relativeSourcePaths": true
        }
    },

It would also be nice if it was possible to reuse linter rubocop config in the ruby formatter config, or at least if it supported the same options. As far as I could figure out it is impossible to configure the formatter for my situation now.

P.S.

The final version of my wrapper script:

#!/bin/bash
docker-compose exec -T spring spring rubocop "${@#$(pwd)/}"

Which makes linter a bit faster. This relies on a spring server running inside a service called spring and spring-commands-rubocop being available in the project's bundle.

[Zhorian]

I resolved the issue. I added a .rubocop file (not .rubocop.yml) and added the following.

--force-exclusion

[januszm]

Is creating the .rubocop file with --force-exclusion the official solution? I ran into this problem with vscode ignoring local .rubocop.yml and so far it's the only solution that helps (I've also considered creating a bin/rubocop wrapper but it's simpler)

[Zhorian]

I think adding this to your .vscode/settings.json is the prescribed way of doing this. This is how I've done it in my recent project.

  "ruby.lint": {
    "rubocop": {
      "forceExclusion": true,
    }
  }

[AlecRust]

forceInclusion method no longer works for me or others, see #227.

My schema.rb has Rubocop errors even though it's excluded in .rubocop.yml:

AllCops:
  NewCops: enable
  Exclude:
    - db/schema.rb

[Zhorian]

I had that exact same issue! I ended up doing this which might be a bit overkill

AllCops:
  Exclude:
    - "node_modules/**/*"
    - "tmp/**/*"
    - "vendor/**/*"
    - ".git/**/*"
    - "db/**/*"
    - bin/**/*

[januszm]

I just checked and indeed, none of the solutions (with .vscode/settings.json or .rubocop files) works if I combine AllCops exclusion with specific cop exclusion, like:

AllCops:
  Exclude:
    - vendor/**/*
    - db/schema.rb
    - db/migrate/*.rb
# ...
Metrics/BlockLength:
  Enabled: true
  Exclude:
    - spec/**/*
    - config/routes.rb

with the above configuration, rubocop is happy when I run it from shell, but complains about BlockLength in routes.rb in VsCode editor window

[AlexVPopov]

I can also confirm the issue occurs even with "forceExclusion": true. @Zhorian Could you, please, reopen the issue?