Improving the Developer Experience with the Ruby LSP

Summary

The Ruby LSP is a language server intended to improve Ruby’s developer experience by providing editor features through the Language Server Protocol, without typechecking code or requiring type annotations. It targets performance and stability in Shopify’s Core monolith, where it must analyze thousands of files that may themselves contain thousands of lines, and is opinionated toward Ruby on Rails. The article explains LSP’s client-server model, in which editors exchange JSON requests and responses over STDIN and STDOUT, then focuses on nonpositional features such as Folding Range, including document synchronization and parsing. It also outlines future work on parallel request processing, codebase indexing, caching, and a plugin system for framework-specific capabilities such as Rails navigation and model information.

Context

Ruby tooling has historically been implemented separately in editor plugins, making features difficult to share across editors and encouraging duplicate implementations. Existing Ruby language servers include Sorbet, Steep, Typeprof, and Solargraph, while the Ruby LSP aims to provide accurate features without typechecking or requiring type annotations. It also needs to remain responsive while handling large Ruby codebases such as Shopify’s Core monolith.

Approach / What changed

The Ruby LSP implements the Language Server Protocol so editors can communicate with a Ruby-specific background server through standardized JSON requests and responses over STDIN and STDOUT. The server synchronizes open documents, analyzes Ruby source for language features, and is designed around performance, stability, and Rails-oriented functionality. Planned extensions include parallel request processing, codebase indexing with possible caching, and a plugin system for framework-specific features.

Takeaways

• LSP standardizes communication between editors and language servers, allowing one Ruby implementation to serve any editor with a compatible client layer.
• Document synchronization keeps the server’s representation of open files current through didOpen, didChange, and didClose notifications; feature requests identify documents by URI rather than including their contents.
• The planned plugin system would let tools and frameworks, including Rails, add editor capabilities without putting all tool-specific functionality in the Ruby LSP’s primary codebase.

Related reading