Consider including the JS compiler as part of this extension? about grain-language-server HOT 3 CLOSED

This is something I'd love to discuss. As ever there are pros and cons.

The pro is that LSP configuration gets a lot easier. Also, because the compiler is integrated, we don't have to spawn a process and endure its associated overhead. and we can also avoid the bodge of piping in on stdin.

The cons for me are several. First, the editor extension is locked to a particular version of the compiler and needs to be rebuilt with each release. Also, you could end up with a different compiler version on your CLI to what the editor is using, which could lead to different compiler errors/warnings from the CLI and the editor. Is this what you address with the Grain source setup when you link the ocaml-lsp?

It always confused me in the Reason world when warned not to run the compiler in watch mode and have the Reason LSP running as both then compile at the same time. I'd like to try and avoid that (a separate issue).

Finally, I want to make the LSP less VS Code specific and more generic LSP. That requires a bunch more thinking about.

Just jotting down some thoughts, feedback welcome

from grain-language-server.

Some more thoughts on this now that I'm starting to work on Go to definition/type declaration/implementation.

A lot of what I need is queryable from the AST. There's a lot of overhead in parsing, converting the AST, passing it over an RPC bridge as JSON, decoding. I'm also pre-querying the definition location of functions, types etc. This is a lot of work done that is often thrown away.

I'd love to have the AST and the Grain libraries like Env.* available in the LSP server. As a half way house I'm pondering just sending the AST and using the JSOO-ed Grain files I need to parse it.

from grain-language-server.

Going to close this, as #100 solves it in a much better way.

from grain-language-server.