castwide / vscode-solargraph

A Visual Studio Code extension for Solargraph.
Other
425 stars 24 forks source link

Solargraph's Gemfile interaction messes up rubocop #141

Open matthewmcgarvey opened 5 years ago

matthewmcgarvey commented 5 years ago

I have a gem installed that adds a rubocop file extension but it is not in my Gemfile. After configuring solargraph to format on save it fails because of missing dependencies which are from the gem. They are installed but, again, are not in my Gemfile. I'm assuming that switching solargraph to use bundler would fix it but I would prefer not to as I manage many ruby codebases and keeping it updated is an annoyance. Is there any way for solargraph to check if I have rubocop in my Gemfile and if so use bundler? I'm thinking that the ruby-rubocop extension does this as it has never had a problem

castwide commented 5 years ago

Could you configure that specific workspace to use Bundler, i.e., in the .vscode/settings.json file?

matthewmcgarvey commented 5 years ago

I'm split on where the real problem is. It seems like solargraph formatting should work whether or not I am using bundler with solargraph. This could be a potential problem for any of the places where solargraph is calling out to a ruby executable as well. But rubocop is not solargraph's focus so why must you handle all these caveats?

Managing lots of codebases with solargraph in the Gemfile causes a lot of noise. I get pop ups in VSCode every time I open the editor and then Dependabot PRs if they're setup. I've moved away from it.

castwide commented 5 years ago

If the other gem is installed on your system, I'm not sure why the RuboCop process doesn't see it, but I almost might be misunderstanding the issue.

RuboCop formatting does, in fact, spawn a new process. If you're not using Bundler to start Solargraph, it shouldn't use it to start RuboCop, either. I can't speak to what RuboCop itself does when it's started in a directory with a Gemfile.

Could it be that you need to add the required extension to .rubocop.yml, or customize the command-line options in .rubocop?

matthewmcgarvey commented 5 years ago

So after looking into it more, it seems like the problem is a bit different. One of the gems I have installed has a rubocop binstub (they did bundle binstubs rubocop) and somehow rubocop run through solargraph is picking it up but running rubocop myself or with the ruby-rubocop extension does not. It seems as though solargraph is picking that as the rubocop command to use and then is failing because the generated binstub is meant to use the Gemfile of the project it is in which is not the one I am using.

TLDR: I think there is an issue in solargraph where it is picking the wrong rubocop executable and using a binstub of a different gem when it shouldn't

castwide commented 5 years ago

The solution here might be to run RuboCop formatting internally from the language server instead of spawning a new process. If my guess is right, the RuboCop diagnostics reporter, which already runs internally for performance purposes, should already work as expected; i.e., it loads the system-level RuboCop gem instead of the modified binstub.