Remove oxc_language_server from npm package oxlint

[Sysix]

Original started here: #12251

I did not want to continue in the issue because this is another direction of the issue.

It's currently a waste to publish our oxlint npm package with two binaries, both containing oxlint,

I had some thoughts, removing the language server binary from npm package oxlint.
See my reasons here #12251 (comment).

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

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

I also checked what other tools do:
VSCode ESLint Plugin comes with the server prebuild, like we do with our VSCode:

https://github.com/microsoft/vscode-eslint/blob/001edda5bd168a9c6a79cba767111ba21eadd052/client/src/client.ts#L384

oxc/editors/vscode/client/extension.ts

Line 154 in 91b9905

join(context.extensionPath, `./target/release/oxc_language_server${ext}`)

In PHPStorm the Vue Language Server comes with the Vue Plugin too. I can change in the PHPStorm Registry the "default version" of the server, and the extension will download it for me.

My Idea:
Make the language server downloadable via GitHub Release.

• VSCode users will have, via the plugin, the newest language server already
• IntelliJ Plugin introduce a default version (like Vue does), users can change them via path definition, or changing the default version in the Registry (@nrayburn-tech)
• Other IDE users can download it from GitHub release or create something similar to IntelliJ Plugin

For Windows Users, having the oxc_language_server.exe inside node_modules is not ideal.
Users can not remove the node_modules folder, because the exe is in use.
@nrayburn-tech created a workaround for the IntelliJ Plugin: oxc-project/oxc-intellij-plugin#239

/cc @Boshen @camc314

[nrayburn-tech]

GitHub releases aren’t approved for use at my company, I expect mine isn’t the only one. This could be a point of friction for users attempting to use a specific version.

I don’t really like the idea of shipping the language server with the IDE plugin. It means that plugin releases need to be made solely to update the language server, which is additional maintenance. If we just need to ship a version, and not always create an IDE release when there’s an Oxlint release I could be ok with this but it’s still not my preference. Users would still need the ability to easily select the version of the language server they use per project.

[Sysix]

GitHub releases aren’t approved for use at my company, I expect mine isn’t the only one. This could be a point of friction for users attempting to use a specific version.

The IDE Plugin should download the server in the background. Not the user :)

[nrayburn-tech]

I don’t think it matters how it gets there. If I want to use something coming from GitHub releases, it’s not approved. Things coming from NPM are because they go through Artifactory and some other things.

I’m not saying it can’t be changed, but I expect that it will be a problem for users.

[nrayburn-tech]

There’s also the issue that if the language server and Oxlint binary are different versions, then users can experience different lint results between the IDE and the CLI. This came up once in Discord.

I think either a single binary with everything in it (like Biome) or multiple binaries with some sort of runtime linking are the best suggestions I have here. Runtime linking in the sense that the language server would be smaller in size, but depend on the normal size Oxlint binary at runtime. Then when oxfmt is introduced, it’s the same thing there.

[Sysix]

There’s also the issue that if the language server and Oxlint binary are different versions, then users can experience different lint results between the IDE and the CLI.

Had this exact problem with vue-language-server, vue-tsc and IntelliJ today. 👍

I see another problem: In a monorepo, there can be different oxlint versions. The language server is fixed on one oxlint version.

[nrayburn-tech]

If you’re using multiple Oxlint versions, wouldn’t you expect multiple Oxc language servers to be used?

I’ve never really understood monorepo setups, but I would expect you have 1 Oxlint installation at the top level and run 1 language servers or you have 1 Oxlint installation per package and you run 1 language server per package.

[Sysix]

wouldn’t you expect multiple Oxc language servers to be used?

No, there should be only one server for me. These are problems that probably every server has.

I think either a single binary with everything in it (like Biome) or multiple binaries with some sort of runtime linking are the best suggestions I have here.

With multiple binaries, there will be different problems:

• Fix should not change the file on the system, instead report it to the client
• Disable rule for line/file needs a bit of span/AST logic, it's not great at the moment, it will be harder when having separate binaries
• Linting on type, oxlint can only read from the file system

[nrayburn-tech]

Multiple binaries would definitely come with interesting problems to solve. Most of which I’m not experienced enough in rust to even attempt to think through.

If you use different Oxlint versions and a single language server, you’re always going to have potential for the IDE and CLI to output different results. That just doesn’t seem ideal.