You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Should the server restart when .ruby-version is changed? #2583
I have checked that this feature is not already implemented
This feature does not exist
Use case
Ruby now plans to to a patch release every two months or so, and repos are inconsistent about updaing their .ruby-version file. Here for example it declares 3.3.4 at the moment even though 3.3.5 is released. I make a habbit of removing previous patch releases when a new one releases and just hand-edit the .ruby-version file, no big deal. But I also have to manually reload the window to make ruby-lsp pick it up.
Should this happen automatically, same as with lockfile changes?
Yes, we should definitely auto-reload if the .ruby-version change. Perhaps just watching the file to trigger the reload is enough? It would be good to give it a try just to ensure it works as expected.
We received this bug report #2411 which is related.
I wonder if which file to watch shouldn't be controlled by the version manager integrations. Maybe the extension's Ruby object can expose something like ruby.versionDefinitionFilePath so that we can use .ruby-version, but also .tools-versions and mise.toml.
Then the Workspace can ask the Ruby object which file to watch and register a watcher like we do for the lockfile.
We ran into this problem at work, where the .ruby-lspdirectory needed to be fully deleted and recreated after we updated Ruby and a lot of our gems at the same time, otherwise we saw pretty weird behaviors.
Happy to take a crack at this. The approach you suggested (Ruby exposing the version definition file path, Workspace watching it like the lockfile) runs through the version manager integrations, and #3894/#3918 are refactoring that same code. Do you want it built on top of that refactor, or watched independently in Workspace for now so it doesn't block on those landing? One open question is which files to cover beyond .ruby-version, since .tool-versions and mise.toml have the same problem.
Activity
vinistock commentedon Sep 20, 2024
Thank you for the feature proposal!
Yes, we should definitely auto-reload if the
.ruby-versionchange. Perhaps just watching the file to trigger the reload is enough? It would be good to give it a try just to ensure it works as expected.We received this bug report #2411 which is related.
I wonder if which file to watch shouldn't be controlled by the version manager integrations. Maybe the extension's
Rubyobject can expose something likeruby.versionDefinitionFilePathso that we can use.ruby-version, but also.tools-versionsandmise.toml.Then the
Workspacecan ask the Ruby object which file to watch and register a watcher like we do for the lockfile.github-actions commentedon Nov 20, 2024
This issue is being marked as stale because there was no activity in the last 2 months
connorshea commentedon Nov 14, 2025
We ran into this problem at work, where the
.ruby-lspdirectory needed to be fully deleted and recreated after we updated Ruby and a lot of our gems at the same time, otherwise we saw pretty weird behaviors.eyupcanakman commentedon Jun 12, 2026
Happy to take a crack at this. The approach you suggested (Ruby exposing the version definition file path, Workspace watching it like the lockfile) runs through the version manager integrations, and #3894/#3918 are refactoring that same code. Do you want it built on top of that refactor, or watched independently in Workspace for now so it doesn't block on those landing? One open question is which files to cover beyond
.ruby-version, since.tool-versionsandmise.tomlhave the same problem.rafaelfranca commentedon Jun 12, 2026
You can ignore the refactors, I'll not merge them.