bug: can't make it work with vscode-eslint-language-server

[LionyxML]

I am trying to run C-u M-x eglot RET and pass lspx --lsp "typescript-language-server --stdio" --lsp "vscode-eslint-language-server --stdio" as the server command.

I get the the typescript language server capabilities, but nothing regarding eslint.

If I try it with only lspx --lsp "vscode-eslint-language-server --stdio" it will also not work.

The *Messages* buffer gives me an eglot warning:
[eglot] (warning) Server tried to register unsupported capability `workspace/didChangeWorkspaceFolders'

On the EGLOT buffer I can see it sending / receiving requests when I save a buffer.

So I tried vscode-eslint-language-server --stdio directly after C-u M-x eglot RET and to my surprise, it also did not worked.

After a bit of digging I found this issue from 2022: joaotavora/eglot#976, which looks like exactly what is happening here (my log is similar).

It looks like this eglot never really got fixed to work with this server, as the answers either tells you to use the flymake-eslint package (non lsp) or tells you to use the eslint plugin that puts messages of eslint lsp inside typescript (now an unsupported plugin for newer versions).

Can you help me dig a bit further? It looks like a real eglot and not lspx bug, and this is a vital lsp server 🤕, if we can confirm I am not the only one who can't use this server with Eglot, maybe an issue to eglot might be better suited.

[cowboyd]

I'm happy to help you dig further! At first look, it seems as though this arguably a bug in vscode-eslint-language-server with potentially a less consequential bug in eglot as well.

The LSP spec is notoriously complex, but If I read it correctly, it seems to me that in the transcript of that session, eglot has told the server that it does not support the workspace.configuration capability, nor does it support dynamic registration of the workspace.didChangeConfiguration and workspace.didChangeWorkspaceFolders capabilties. As such, vscode-eslint-language-server has no business trying to dynamically register those capabilities, nor does it have any business issuing a workspace.configuration request given that eglot has explicitly told it not to.

That said, on the eglot side, the bogus dynamic registration succeeds:

[server-request] (id:0) Thu Jun 16 15:35:41 2022:
(:jsonrpc "2.0" :id 0 :method "client/registerCapability" :params
          (:registrations
           [(:id "dcfa99a0-12bc-4d8d-b2da-14ed6d106182" :method "workspace/didChangeConfiguration" :registerOptions nil)]))
[client-reply] (id:0) Thu Jun 16 15:35:41 2022:
(:jsonrpc "2.0" :id 0 :result nil)
[server-request] (id:1) Thu Jun 16 15:35:41 2022:
(:jsonrpc "2.0" :id 1 :method "client/registerCapability" :params
          (:registrations
           [(:id "234a266a-0363-4598-ba68-392b41dd2801" :method "workspace/didChangeWorkspaceFolders" :registerOptions nil)]))
[client-reply] (id:1) Thu Jun 16 15:35:41 2022:

And so then the vscode-eslint-language-server sends the notifications anyway (and perhaps justifiably so?). My guess is that the dynamic registration should fail, but this is a minor issue in that eglot probably just ignores these notifications anyway, and the bulk of the issue is the server invoking a capabilities which is explicitly absent.

All that said, this is one of the spaces that a tool like lspx can fill!

To dynamically patch up gaps in communication between LSP client and server. I think we should be able to provide a "middleware" to add things like "workplace.configuration" defaults. In fact, I see the ability to add plugins and middleware to lspxon a per-project basis as a key direction for the tool.

[LionyxML]

Ohhh I see it.

Well, you're right, lspx with some middleware system is a great idea.

I took a pick on the lsp-mode implementation for this server, I could not understand how to fix it on eglot tough, if you feel inspired here it is: https://github.com/emacs-lsp/lsp-mode/blob/master/clients/lsp-eslint.el

I think on eglot we miss something like: https://github.com/emacs-lsp/lsp-mode/blob/master/clients/lsp-eslint.el#L261C5-L261C6

But I might be wrong.

GitHub

lsp-mode/clients/lsp-eslint.el at master · emacs-lsp/lsp-mode

Emacs client/library for the Language Server Protocol - emacs-lsp/lsp-mode

GitHub

lsp-mode/clients/lsp-eslint.el at master · emacs-lsp/lsp-mode

Emacs client/library for the Language Server Protocol - emacs-lsp/lsp-mode

[cowboyd]

How about this as an approach: We introduce the concept of middleware and then write a middleware to provide a default workspace configuration if none is provided. Then, if that works well, we can think about making the middleware pluggable. I wonder wha the workspace configuration we return be given what little context we have (I think we basically know the current working directory of lspx and that's about it.

[LionyxML]

Sounds like a plan!

Regardless of where lspx is installed, an optional --work-directory option should be available. This would allow Emacs users to call it like this:

C-u M-x eglot RET lspx --work-directory  'PATH' ...

Emacs users would likely create a function to configure Eglot, using (project-root (project-current)) to provide the appropriate PATH.

If necessary, we could also introduce middleware-specific options, such as --vscode-eslint-config-file-regex, to further customize the setup.

[cowboyd]

@LionyxML Step one is complete. We have middleware. Now the question is: what should the conversation between vscode-eslint-language-server and lspx look like.

[cowboyd]

@LionyxML I don't use eslint myself. Do you have a public project configured that I can use for testing?

[LionyxML]

Here's a sample project:

https://github.com/LionyxML/react-ts-eslint-prettier-sample

A screenshot of all errors (typescript and eslint (and prettier via eslint plugin)) via LSP on neovim:

It expects nodejs 23.7.0, you can install it with npm install.

You can run eslint as a regular linter (non lsp) on terminal with npx eslint and have something like this:

And files containing errors are:

src/App.tsx
src/main.tsx

I hope it helps :)

GitHub

GitHub - LionyxML/react-ts-eslint-prettier-sample: A sample project to test lspx with typescript + eslint servers

A sample project to test lspx with typescript + eslint servers - LionyxML/react-ts-eslint-prettier-sample

[cowboyd]

Where do you get the actual vscode-eslint-language-server executable from? Is it from here ? https://github.com/hrsh7th/vscode-langservers-extracted

GitHub

GitHub - hrsh7th/vscode-langservers-extracted: vscode-langservers bin collection.

vscode-langservers bin collection. Contribute to hrsh7th/vscode-langservers-extracted development by creating an account on GitHub.

[LionyxML]

I have an alias I execute every time I enter a new node project (usually with asdf or nvm to change versions), it installs all that I need:

npm i -g vscode-langservers-extracted prettier typescript-language-server typescript eslint

This extracted is the way to get it (VSCode likes to make stuff harder), so yeah, this place: https://www.npmjs.com/package/vscode-langservers-extracted

npm

vscode-langservers-extracted

HTML/CSS/JSON/ESLint language servers extracted from [vscode](https://github.com/Microsoft/vscode).. Latest version: 4.10.0, last published: a year ago. Start using vscode-langservers-extracted in your project by running `npm i vscode-langservers-extracted`. There is 1 other project in the npm registry using vscode-langservers-extracted.

[cowboyd]

@LionyxML After more digging, it looks like this is definitely a bug in the vscode-eslint-language-server. From the spec:

If the client can’t provide a configuration setting for a given scope then null needs to be present in the returned array.

That said, I'm trying to figure out what the shape of the object it expects back is so that I can patch the response.

[cowboyd]

Essentially, the server sends the client workspace/configuration with this:

{
  items: [
    {
      scopeUri: "file:///Users/cowboyd/Code/@cowboyd/react-ts-eslint-prettier-sample/src/App.tsx",
      section: ""
    }
  ]
}

And currently eglot is responding with

[ null ]

And so we need to understand what the proper response. I think it needs to be something like:

[
  {
    workingDirectory: ??
  }
]

But can't figure out the shape.

[LionyxML]

Thanks for filing the vscode-eslint issue. I totally missed your message.

My best bet regarding setting up communication was to study what lsp-mode does and if they made some 'patch' to avoid this issue (https://github.com/emacs-lsp/lsp-mode/blob/master/clients/lsp-eslint.el#L307).

I cant't tackle this now :/ , tell me if you spot some nice insight!

Edit: maybe something here also: https://github.com/esmuellert/nvim-eslint

[cowboyd]

Hmmm... I was able to use the defaults provided by those libraries and get the eslint server to start properly, but I still could not get it to send diagnostics....