Add initialization option bypassTypechecker #3777
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Currently, when working on the
ruby-lsprepository in editors that support the Language Server Protocol (LSP) but do not support workspace configuration (such as Zed), developers are required to use theRUBY_LSP_BYPASS_TYPECHECKERenvironment variable. However, this approach can be problematic, as not all editors provide a straightforward way to define or persist environment variables for LSP servers.Additionally, in VS Code extension, the
rubyLsp.bypassTypecheckerworkspace configuration is used to set theRUBY_LSP_BYPASS_TYPECHECKERenvironment variable, which is then passed to the LSP executable. While this works well for VS Code, it introduces unnecessary indirection and editor-specific handling.By supporting this configuration directly through
initializationOptions, we can simplify the setup and make the behavior consistent across all editors. TheinitializationOptionsfield is part of the LSP specification and is supported by all compliant editors, making this a more portable and standard solution.Closes #2856
Implementation
The change introduces support for the
bypassTypecheckeroption in the LSPinitializationOptions. Previously, this behavior could only be controlled through theRUBY_LSP_BYPASS_TYPECHECKERenvironment variable or the VS Code workspace configuration. Now, the option can be passed directly during LSP initialization, making it editor-agnostic and compliant with the LSP specification.The implementation updates
GlobalStateto respectinitializationOptions[:bypassTypechecker], adjusts the VS Code client to forward this setting through initialization options instead of environment variables, and adds a dedicated test to verify the new behavior. Reviewers should confirm that backward compatibility with the environment variable remains intact and that the change does not affect Sorbet detection in normal use.Automated Tests
A new unit test was added to verify that
bypassTypecheckercorrectly disables type checker detection when provided throughinitializationOptions. Existing tests continue to cover the environment variable path, ensuring backward compatibility.All tests pass locally.
Manual Tests
Below are step-by-step instructions to validate the new
bypassTypecheckerinitialization option in VS Code when working in theruby-lsprepo.Prerequisites
ruby-lsp.code-workspace.bundle install) and the Ruby LSP VS Code extension is enabled.bypassTypecheckeris off.1) Verify behavior with
bypassTypechecker: truerubyLsp.bypassTypechecker = truerubyLsp.trace.server = "verbose".lib/ruby_lsp/global_state.rb).initializepayload contains:2) Verify behavior with
bypassTypechecker: falserubyLsp.bypassTypechecker = false(or remove it).“Ruby LSP detected this is a Sorbet project and will defer to the Sorbet LSP for some functionality.”