x/tools/gopls: move jsonrpc2_v2 out of internal

[glennsarti]

This is probably better classed as a Feature Request, than issue.

The gopls is designed purely for the Go language. But it would we great if other languages could use the same library to create LSP Servers for more than just Go. For example:

• https://github.com/Kirides/DaedalusLanguageServer

• https://github.com/hashicorp/terraform-ls

• https://github.com/go-language-server/protocol

Both of these had to create the LSP (or vendor it).

Are there any plans to release the LSP and JSON RPC packages so they can consumed as a library instead of having to vendor it?

I've had a look at the jsonrpc_v2 work and it looks really good!

What version of Go are you using (go version)?

N/A

Does this issue reproduce with the latest release?

N/A

What operating system and processor architecture are you using (go env)?

N/A

What did you do?

N/A

What did you expect to see?

N/A

What did you see instead?

N/A

[crossphoton]

Can you once go through this page and tell whether what you're suggesting is similar.

https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/

[glennsarti]

Hi @crossphoton . Yes I've read that. But I don' really know what you're asking of me here.

The internal gopls packages implement the LSP. I'm wondering if those internal packages could be no-longer internal

[crossphoton]

@glennsarti Just confirming what we're trying to achieve here 😀.

[glennsarti]

To give some background ... I maintain the Puppet Language Server and I'd like to move to Golang (There's a Puppet Lang Lexer and Parser in Go), for amongst other things, speed.

But the last thing I want to do is create yet-another-LSP implementation when there's already a rock solid on in gopls

I've been playing around with a vendored version and so far all I need is:

• internal/jsonrpc2
• internal/lsp/debug
• internal/lsp/protocol
• internal/span
• internal/xcontext

I'd love to use jsonrpc2_v2 but it still has work to do as the protocol still uses the older jsonrpc2 stuff.

[findleyr]

CC @ianthehat

@glennsarti I don't know the answer to your question, but I'll give you my perspective. I think we want to move some of the packages you mention out of internal eventually (see note below regarding jsonrpc2), but right now the team does not have the time to (1) fix some things we know we want to fix before making these packages more generally available, and (2) support them externally.

The cost of (2) goes down the more detached packages are from the internals of gopls. For example, the jsonrpc2 package could probably be made external (albeit in an experimental form) once we fix some of its problems. I think part of the reason Ian worked on jsonrpc2_v2 is so that it can eventually be made public. Right now, it's on me to integrate that package with gopls, and I just haven't had time yet -- hopefully with the 1.17 freeze that will change soon.

[ianthehat]

Yes, the purpose of writing jsonrpc2_v2 was to be able to make it a public supported package.
The span package needs a rethink, it causes too many gotchas right now, but it could be public.
xcontext is fairly trivial, and possibly not needed in the long run (it is mostly used to maintain spans, and we are hoping to change that mechanism)
the dependency on lsp/debug will hopefully be cut
That just leaves the protocol package, which it is much harder to make public. The public interface is generated from the lsp definition, which means it has a tendency to change in a way that breaks our normal compatibility promises. We might be able to make it a bit easier to just run the generator that way you can just generate a copy for your use customized to your lsp implementation, rather than trying to allow you to use our copy.

[pjweinb]

It would be hard to give any guarantees about the generated code (tsprotocol.go, tsserver.go, tsclient.go), or the code that genewrates it (in the directory protocol/typescript). The generating code is filled with heuristics, and depends on possibly evanescent details in the typescript implementation.

[stamblerre]

I think we agree that the jsonrpc2 package will be made public, the but the protocol package is not stable enough to move out of internal. You are welcome to copy the generator and use it in your own repository, however.

[glennsarti]

Thanks all for taking the time to respond! I'm not expecting any timelines or firm decisions from this. So I'm happy for this issue to be closed, if there's a better place for "roadmap" questions like this.

[glennsarti]

FWIW ... I've looked at the code generator and it's ... quite difficult to understand. There seems to be a lot of "go-isms" in the typescript code. I don't mean to disparage the author(s) (@pjweinb and co.). I myself have had to write something similar for my Ruby based Language Server and it's really really really really hard!. The Language Server people didn't do us non-Typescript people any favours 😁

That said, I'm working on a rewrite of my parser of the vscode-languageserver-node typescript code and I'm more than happy to share what I've done/doing with gopls team.

[ianthehat]

What we really want is a language neutral API spec, rather than having to parse the typescript.
We considered trying to generate one as an intermediate step so we could separate parsing the protocol from generating the go code, but the API is hard to represent in any of the existing languages, it is so tightly coupled with typescript.

[glennsarti]

What we really want is a language neutral API spec, rather than having to parse the typescript.

SO MUCH THIS!!

but the API is hard to represent in any of the existing languages, it is so tightly coupled with typescript.

Completely agree. I did see an attempt to generate a JSON Schema spec which would be better but it doesn't seem to have been finished. 😢

[glennsarti]

yeah ... as per microsoft/language-server-protocol#67 (comment)

[bcmills]

(CC @adonovan @findleyr)

[JonahSussman]

@findleyr @ianthehat

Was wondering what what the status of the jsonrpc2 library is in relation to jsonrpc2_v2. Is v2 considered "up to snuff" and where all the active development is? Looking at the two pkg.go.dev pages here and here it seems like it is. Want to make sure that I'm looking at the correct package with active development on it!