Feature Request: Language Server Protocol (LSP) Implementation

[qiuethan]

Summary

Currently, IDE support is limited to a specific VS Code extension. To support the broader developer ecosystem (Neovim, IntelliJ, Sublime Text, Zed, etc.), we should extract the linting logic into a standard Language Server Protocol (LSP) server.

Problem

• Maintaining a specific VS Code extension couples the tool to one editor.
• Users of other editors have to rely on the CLI, missing out on real-time "squiggles" and feedback.

Proposed Solution

Create a new package @archctl/language-server.

Key Capabilities

1. Standard LSP Features:
   • textDocument/publishDiagnostics: Show errors/warnings on imports.
   • textDocument/hover: Show layer/context info when hovering a file header.
   • textDocument/codeAction: Provide "Quick Fixes" (see Auto-Fix feature).
2. Editor Agnostic: The core logic handles the analysis, and any LSP-compliant client can consume it.

Implementation Plan

1. Refactor vscode-extension code to separate VS Code specifics from the analysis logic.
2. Use vscode-languageserver-node to implement the server.
3. Update the VS Code extension to simply be a client for this new server.
4. Publish instructions for configuring Neovim (nvim-lspconfig) and other editors.

[angelozerr]

If you want to provide support for IntelliJ you will have 3 choices:

1. developping an IJ plugin based on LSP from JetBrains
2. or developping an IJ plugin based on https://github.com/redhat-developer/lsp4ij
3. or if you have no skills to develop an IJ plugin, you can do that with few settings with LSP4IJ https://github.com/redhat-developer/lsp4ij/blob/main/docs/UserDefinedLanguageServer.md and LSP4IJ could even host your language server as default template https://github.com/redhat-developer/lsp4ij/blob/main/docs/UserDefinedLanguageServer.md#using-template

For the 2 and 3 solutions I could help you.

[qiuethan]

Thanks Angelo. This helps a lot.

My plan is to first extract the core analysis into a standalone @archctl/language-server using vscode-languageserver-node, and then update the VS Code extension so it works as a thin LSP client.

Since I have never built an IntelliJ plugin before, I am planning to start with the LSP4IJ UserDefinedLanguageServer setup so I can get basic IntelliJ support without writing a full plugin. After the LSP is stable, I can move to a dedicated LSP4IJ plugin if needed.

Does this approach make sense?

[angelozerr]

Thanks Angelo. This helps a lot.

You are welcome!

My plan is to first extract the core analysis into a standalone @archctl/language-server using vscode-languageserver-node, and then update the VS Code extension so it works as a thin LSP client.

Since I have never built an IntelliJ plugin before, I am planning to start with the LSP4IJ UserDefinedLanguageServer setup so I can get basic IntelliJ support without writing a full plugin. After the LSP is stable, I can move to a dedicated LSP4IJ plugin if needed.

Does this approach make sense?

You understood totally what I am trying to explain you!

If your language server doesnt require some lsp custom command, user defined ls is perfect and I suggest that you contribute to LSP4IJ with default template.

I suggest that you publish your language server in npm registry or you publish it in releases github in order to you write a json installer to install your server automaticly with lsp4ij when server starts.