Open matthewmcgarvey opened 5 years ago
Could you configure that specific workspace to use Bundler, i.e., in the .vscode/settings.json
file?
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.
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
?
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
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.
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 myGemfile
. 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 myGemfile
and if so use bundler? I'm thinking that theruby-rubocop
extension does this as it has never had a problem