Skip to content

Allow sending add-on languages to the server - #4270

Open
bjeanes wants to merge 1 commit into
Shopify:mainfrom
bjeanes:addon-language-ids
Open

bjeanes wants to merge 1 commit into
Shopify:mainfrom
bjeanes:addon-language-ids

Conversation

@bjeanes

@bjeanes bjeanes commented Nov 11, 2026

Copy link
Copy Markdown

Motivation

Related to #1233.

An add-on can make the server handle a language besides Ruby and ERB. For example, my prototype add-on, ruby-lsp-slim-lang, does this for the Ruby inside Slim templates. That follows @vinistock wondering in #1233 whether templating engines may be a better fit for add-ons2.

However, the extension only sends Ruby and ERB files to the server. As such, an add-on like that can't be used from VS Code. In Neovim, where the client's ruby_lsp config decides which file types to send, adding slim to it is enough for the add-on to work.

Implementation

This adds a rubyLsp.addonLanguageIds setting, empty by default. The extension adds each language ID listed there alongside Ruby and ERB in:

  • the client's document selector,
  • the language status items, and
  • the checks that activate a workspace when a document opens.

It's opt-in, because without a matching add-on the server would parse those files as Ruby.

Since any change under rubyLsp restarts the server, the client picks up the new list when it rebuilds its document selector. However, the language status items only read the list when the extension activates. They won't show a change to the setting until the window is reloaded, which I've left as is to keep this change small.

The extension's ERB delegation middleware checks for erb explicitly. Requests for other languages therefore go straight to the server.

Note

The add-on API has no way to register a document type, though @vinistock suggested in #1233 that one might be designed. So, ruby-lsp-slim-lang currently patches the server's document store to create its own. That is separate from this change, which only concerns which files the extension sends.

I made this change with Claude Code, which is why the commit has a Co-Authored-By trailer. I've reviewed it and tested it in VS Code myself, and I'm happy to drop the trailer if you'd prefer.

Automated Tests

I added unit tests for the list of supported language IDs, both by default and with the setting.

Manual Tests

  1. In a Ruby project that uses Slim, add gem "ruby-lsp-slim-lang", require: false, github: "bjeanes/ruby-lsp-slim-lang" to the Gemfile and run bundle install.
  2. Install a Slim syntax extension, so that .slim files get the slim language ID.
  3. Add "rubyLsp.addonLanguageIds": ["slim"] to the workspace settings, then reload the window.
  4. Open a .slim template and go to the definition of a helper or constant it uses. It should jump to the Ruby definition.
  5. Remove the setting and reload the window. Go to definition in the template should no longer find anything.

An add-on can make the server handle a language besides Ruby and ERB.
For example, my add-on, ruby-lsp-slim-lang, does this for the Ruby
inside Slim templates. Since the extension only sends Ruby and ERB files
to the server, an add-on like that can't be used from VS Code.

This adds a `rubyLsp.addonLanguageIds` setting, empty by default. The
extension adds each language ID listed there alongside Ruby and ERB in
the client's document selector, in the language status items, and in the
checks that activate a workspace when a document opens. It's opt-in,
because without a matching add-on the server would parse those files as
Ruby.

Since any change under `rubyLsp` restarts the server, the client picks
up the new list when it rebuilds its document selector. The language
status items only read the list when the extension activates, however. A
change only reaches them after a window reload, which I've left as is to
keep this change small.

For context, the add-on API has no way to register a document type,
though @vinistock suggested in Shopify#1233 that one might be designed[1]. So,
ruby-lsp-slim-lang currently patches the server's document store to
create its own. That is separate from this change, which only concerns
which files the extension sends.

[1]: Shopify#1233 (comment)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@bjeanes
bjeanes requested a review from a team as a code owner November 11, 2026 02:22
@bjeanes

bjeanes commented Nov 11, 2026

Copy link
Copy Markdown
Author

I have signed the CLA!

@bjeanes bjeanes mentioned this pull request Nov 11, 2026
1 task done
bjeanes added a commit to bjeanes/ruby-lsp-slim-lang that referenced this pull request Nov 11, 2026
The README said VS Code wasn't supported, because the Ruby LSP extension
only sends Ruby and ERB files to the server. I've opened
Shopify/ruby-lsp#4270 to add a `rubyLsp.addonLanguageIds` setting that
sends other languages too. Until a release of the extension includes
it, the README explains how to build the extension from my fork and
which settings to use.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant