Skip to content

Should the server restart when .ruby-version is changed? #2583

Open

Description

@Earlopain

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?

Description

See above

Implementation

No response

Activity

  1. vinistock commented on Sep 20, 2024

    @vinistock
    Member

    Thank you for the feature proposal!

    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.

  2. github-actions commented on Nov 20, 2024

    @github-actions
    Contributor

    This issue is being marked as stale because there was no activity in the last 2 months

  3. added
    pinnedThis issue or pull request is pinned and won't be marked as stale
    and removed on Nov 20, 2024
  4. removed their assignment
    on Dec 16, 2024
  5. connorshea commented on Nov 14, 2025

    @connorshea

    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.

  6. eyupcanakman commented on Jun 12, 2026

    @eyupcanakman
    Contributor

    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.

  7. rafaelfranca commented on Jun 12, 2026

    @rafaelfranca
    Member

    You can ignore the refactors, I'll not merge them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesthelp-wantedExtra attention is neededpinnedThis issue or pull request is pinned and won't be marked as stale

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions