rubocop not using .rubocop.yml file

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

Interestingly this seems to occur when using Solargraph diagnostics too!

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

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

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

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

@Zhorian

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.

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

--force-exclusion

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)

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,
    }
  }

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

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/**/*

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

@Zhorian

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

@Zhorian

Hey @Zhorian , sorry, it seems that "useBundler": true was causing the problem on my side, no need to reopen the issue.

@Zhorian

I have this on my settings.json file for VSCode:

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

And my .rubocop.yml is being ignored.
Is there any way to specify which path the config file can be found?
Or any pointers on how to configure it so it'll pick up the yml file at the project's root?

UPDATE:

I used @Zhorian code, and it seems to be working now:

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

This issue is still an issue. Probably, this bot should be disabled due to #815.

@benzado

According to my testing it seems that any exclusion pattern that points to a specific file name won't work. For example, if we have a file named file.rb with a Metrics/BlockLength linting error and I use this rule in .rubocop.yml, then it won't actually be ignored:

Metrics/BlockLength:
  Exclude: 
    - '**/file.rb'

But, if I move the file to the lib directory and change the exclusion pattern like so, the linting errors will be ignored:

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

I can confirm that @benzado's conclusion is correct and #720 does indeed fix the issue, since I manually edited the file ~/.vscode/extensions/rebornix.ruby-0.28.1/dist/server/index.js replacing

`'${i.URI.parse(this.document.uri).fsPath}'`

with:

i.URI.parse(this.document.uri).fsPath

and single file exclusion patterns are now working (after restarting VSCode).

@ricardograca

I made the same modification as @ricardograca and the .rubocop.yml setting is reflected.
Thank you @ricardograca !

That was supposed to be only a test, but indeed it does the trick until we get a more permanent solution.

Worked for me too, I finally see rubocop ignoring Metrics/BlockLength in my rspec files. 🥳

@ricardograca

The solution by @ricardograca worked for me as well. Thank you!

You can use this oneliner to apply his fix (VSCode must be restarted afterwards):

sed -i .bak "s/\`'\${i.URI.parse(this.document.uri).fsPath}'\`/i.URI.parse(this.document.uri).fsPath/g" ~/.vscode/extensions/rebornix.ruby-0.28.1/dist/server/index.js

It will save a backup of the original file to index.js.bak.

I've been using the solution here for a while and it's been good so far. I noticed this morning however that it isn't working with AllCops rules. For example, I'm now seeing BlockLength errors in routes.rb despite it being excluded.

This does not work:

AllCops:
  Exclude:
    - 'config/**/*'

But this works:

Metrics/BlockLength:
  Exclude:
    - 'config/**/*'

I wonder, when could we get at least the partial fix officially released?

@ricardograca

Thank you, @ricardograca and @m-o-e! I can confirm #578 (comment) worked for me 🙌 at least for some cops. Not sure if I will run into something else as described in #578 (comment)

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

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

We're waiting for 2+ years, bots interfer, forcing to flood useless messages like this one.

@m-o-e

On Ubuntu, I had to adapt the command from @m-o-e to

sed -i.bak "s/\`'\${i.URI.parse(this.document.uri).fsPath}'\`/i.URI.parse(this.document.uri).fsPath/g" ~/.vscode/extensions/rebornix.ruby-0.28.1/dist/server/index.js

(removed the space between -i and .bak, might be a macOS vs linux issue).

@m-o-e

On Ubuntu, I had to adapt the command from @m-o-e to
(removed the space between -i and .bak, might be a macOS vs linux issue).

And here's the explanation why: https://unix.stackexchange.com/questions/281543/is-my-interpretation-of-sed-i-bak-x-d-some-file-correct

Navigation Menu

Repository navigation

rubocop not using .rubocop.yml file #578

Your environment

Expected behavior

Actual behavior

Context

Solving the problem in my context

Suggestions for the extension config

P.S.

13 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

rubocop not using .rubocop.yml file #578

Description

Your environment

Expected behavior

Actual behavior

Activity

Zhorian commented on Jan 4, 2020

andrewmcodes commented on Jan 7, 2020

Zhorian commented on Jan 9, 2020

artm commented on Jan 10, 2020

artm commented on Jan 10, 2020

Context

Solving the problem in my context

Suggestions for the extension config

P.S.

Zhorian commented on Jan 12, 2020

januszm commented on Mar 8, 2021

Zhorian commented on Mar 8, 2021

AlecRust commented on Mar 8, 2021

Zhorian commented on Mar 8, 2021

januszm commented on Mar 8, 2021

AlexVPopov commented on Apr 13, 2021

AlexVPopov commented on Apr 13, 2021

lobo-tuerto commented on Jun 18, 2021

13 remaining items

AlexWayfer commented on Aug 19, 2022

ricardograca commented on Sep 24, 2022

y-amadatsu commented on Sep 26, 2022

ricardograca commented on Sep 27, 2022

gregawoods commented on Sep 28, 2022

m-o-e commented on Oct 16, 2022

gregawoods commented on Nov 15, 2022

mcelicalderon commented on Nov 22, 2022

github-actions commented on Mar 23, 2023

AlexWayfer commented on Mar 23, 2023

severinraez commented on Jul 6, 2023

januszm commented on Jul 6, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions