search

castwide / vscode-solargraph

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

Bundler workflow #105

Closed thomthom closed 5 years ago

thomthom commented 5 years ago

Since RuboCop updates so often with breaking changes or adding new warnings I've lately configured my projects to have Solargraph use Bundler.

However, when I do so it appear that I need to add solargraph to my Gemfile. But then I also lock the solargraph version to whatever is in Gemfile.lock. When there's an update of Solargraph this message pops up:

image

But even if it's installed, it appear that the solargraph version in Gemfile.lock is used - so the update message persist.

It's inconvenient to have to update the Gemfile.lock and check it in everytime solargraph updates. Especially when you are in a feature branch.

My ideal scenario would be to have solargraph use the gems from my Gemfile for stuff like RuboCop - but have solargraph itself always be loaded from the latest system gem. Would something like this be possible?

castwide commented 5 years ago

Did you set "solargraph.useBundler" : true in your VS Code settings? Otherwise, Solargraph should use the system gem. There might be exceptions depending on the environment.

Right now, useBundler is the easiest way to enforce gem versions for both the server's runtime and the loaded documentation. I've been looking into alternatives. One possibility is for Solargraph to parse Gemfile.lock for version numbers. I was looking into that feature primarily to determine which versions of YARD documentation to load, but it might be possible to use the same process to determine which version of RuboCop to run. Is that in line with what you were thinking?

thomthom commented 5 years ago

Yea, my problem is that I have multiple projects going at the same time that uses different RuboCop versions. Updating all at once gets messy quickly and makes it difficult on work on larger features.

Because of that I used "solargraph.useBundler" : true to lock down the RuboCop version for each project. Makes sense due to the nature of RuboCop and YARD - they are tried closer to the project. But with Solargraph I kindof wish I it would be possible to always use latest system gem version instead of adding it to the Gemfile.

thomthom commented 5 years ago

One possibility is for Solargraph to parse Gemfile.lock for version numbers.

Yea, that work cover the update notifications. But I do like to have Solargraph kept up to date. It has stayed backwards compatible without adding unwanted noise - as oppose to RuboCop's updates where each update require project tweaking.

castwide commented 5 years ago

This issue might be mitigated in the current version of the gem. Among other things, it can execute a separate process to read a project's gem dependencies without requiring Solargraph to be one of them. Of course, useBundler is also still an option.

If you still have problems with it, please feel free to reply or open a new issue.

thomthom commented 5 years ago

Do you mean 0.35.1?

thomthom commented 5 years ago

Does this mean if I should remove useBundler from my settings? Or is it obsolete an unused now?

castwide commented 5 years ago

Yes, 0.35.1 should have it. The new bundle inspection was added in 0.34, IIRC.

useBundler isn't obsolete, but it's necessary in fewer circumstances. One reason you might still need it is if your project has cached or vendored gems.

thomthom commented 5 years ago

I tried it on one of my projects, removing solargraph from the Gemfile and removed useBundler. Using the Restart Solargraph command yielded an error. But closing the project and reopening made it work.

Thank you for this improvement, this makes it a lot easier to work with version control without having to update Gemfile.lock all the time.

thomthom commented 5 years ago

I now ran into a new issue again. RuboCop changes a lot between versions, often breaking changes. So I have different projects using different RuboCop versions.

After I removed useBundler from my project configs so that I don't have to check in changes for every solargraph update I now have the problem that Solargraph is trying to use the latest RuboCop installed.

Among other things, it can execute a separate process to read a project's gem dependencies without requiring Solargraph to be one of them.

Does this mean it should be loading RuboCop based on Gemfile.lock?

castwide commented 5 years ago

That process only determines which gem versions should be added to the code maps. It won't affect which version of RuboCop gets executed.

This is a tough one. The RuboCop diagnostics reporter is integrated into the language server, so changing the RuboCop version isn't as simple as specifying a path to the executable. I'm not sure of the best way to solve this, but I'm open to suggestions.

ccarse commented 3 years ago

I constantly run into this same issue. I'd like to use the system version of solargraph but always use the bundle versions of everything that solargraph inspects/runs. I'd like it to use my bundle's rubocop etc. Maybe in addition to useBundler there could be a useSystemSolargraph?