Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: move jsonrpc2_v2 out of internal #46187

Open
glennsarti opened this issue May 15, 2021 · 13 comments
Open

x/tools/gopls: move jsonrpc2_v2 out of internal #46187

glennsarti opened this issue May 15, 2021 · 13 comments

Comments

@glennsarti
Copy link

@glennsarti glennsarti commented May 15, 2021

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:

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

@gopherbot gopherbot added this to the Unreleased milestone May 15, 2021
@crossphoton
Copy link

@crossphoton crossphoton commented May 17, 2021

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
Copy link
Author

@glennsarti glennsarti commented May 17, 2021

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
Copy link

@crossphoton crossphoton commented May 17, 2021

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

@glennsarti
Copy link
Author

@glennsarti glennsarti commented May 17, 2021

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
Copy link
Contributor

@findleyr findleyr commented May 17, 2021

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.

@findleyr findleyr removed this from the Unreleased milestone May 17, 2021
@findleyr findleyr added this to the gopls/unplanned milestone May 17, 2021
@ianthehat
Copy link

@ianthehat ianthehat commented May 17, 2021

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
Copy link

@pjweinb pjweinb commented May 17, 2021

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
Copy link
Contributor

@stamblerre stamblerre commented May 17, 2021

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.

@stamblerre stamblerre changed the title x/tools/gopls Will the LSP and JSON RPC pacakges be "publicly" available instead of internal only. x/tools/gopls: move jsonrpc2_v2 out of internal May 17, 2021
@glennsarti
Copy link
Author

@glennsarti glennsarti commented May 18, 2021

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
Copy link
Author

@glennsarti glennsarti commented Jun 2, 2021

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
Copy link

@ianthehat ianthehat commented Jun 2, 2021

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
Copy link
Author

@glennsarti glennsarti commented Jun 2, 2021

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
Copy link
Author

@glennsarti glennsarti commented Jun 2, 2021

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants