I see the language server as an own project beside oxlint.
Yes, currently it is only supporting what oxlint does, but the server could do much more.

textDocument/formatting like oxfmt will do in the future
textDocument/documentSymbol, resolving symbols to other file (CTRL + click on imported variable). oxc_semantic could be helpful for that. I do not see the need because other language-server like ts, vue, astro and svelte should implement it.
- If we fully support a/all special parsers, we can think about unifying them

The binary for the language server has another goals. It should keep running and be requested with the Language-Server-Protocol.
Not every LSP Client will support the same thing, so we should check for the ClientCapabilities and change the behavior for the server. As an example, it could wait for the linter/formatter or send partial result when receiving streams.

Handling all the use cases an LSP Client could support has nothing to do inside the oxlint binary.

The rule react/forward-ref-uses-ref has two possible fixes in the editor. Only one in oxlint. That because the user can select different options for a diagnostic. Fix it, fix it in another way, disable it for this line, and disable it for this document.

Keeping the two binaries separated will keep us will better LSP integration and possible some performance improvements.
The semantics could be shared between tools. Every oxc tool should implement an interface which the language server can use. Executing a binary one time and keeping it all running are two different scenarios and should be optimized for it.

Uh oh!

oxlint: Single binary for oxlint and oxc_language_server #12251

Description

Sub-issues

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

oxlint: Single binary for `oxlint` and `oxc_language_server` #12251