tsserver should implement the Language Server Protocol
leungbk opened this issue · 62 comments
Search Terms
language server protocol
Suggestion
As the language server protocol ( https://github.com/Microsoft/language-server-protocol ) is getting more and more popularity and clients ( https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations ), it would be very useful to have the tsserver implement this protocol.
This is a duplicate of issue #11274, which the OP closed because at that time, there existed two reasonable-looking LSP implementations for TypeScript.
But the times have changed. The Theia IDE now uses a VS Code extension for its TypeScript needs, and in the last eighteen months, Sourcegraph's server has received exactly one update by a sentient person.
There continue to be requests for LSP support within #11724 despite its Closed status. The OP has expressed no interest in revisiting the issue.
Use Cases
It would be useful to programmers who use TypeScript but don't use VS Code.
Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
- This feature would agree with the rest of TypeScript's Design Goals.
Is there any traction on this? I feel like this should be somewhat high priority, but only because my favorite IDE's all blame TypeScript's non-conformance to the Language Server Protocol as the reason TypeScript support is buggy.
How bad is this issue, and how difficult would it be to remedy? Thanks. I'd also be interested in links to reading material that might enlighten me on the subject.
We're working on this, albeit slowly. tsserver's implementation predates LSP so it's nontrivial work to move forward in a way that doesn't adversely affect old clients or result in code duplication.
Your favorite IDE should misplace their blame somewhere else 🙃
@RyanCavanaugh If you are looking for a testing environment may I suggest vim with vim-lsp.
@RyanCavanaugh is there a branch to track? Or what is the best way to track the work on that?
@RyanCavanaugh In line with last comment: any list of issues/tasks that someone could tackle on free time to help with this?
From Eclipse Wild Web Developer perspective, we'd also gladly participate in some testing of this feature when it's available for experiments. We're not looking for a 100% LSP conformance from day 1, we're just looking for a sustainable and more standard alternative to the https://github.com/theia-ide/typescript-language-server and we'd gladly migrate to standard tsserver LSP support even if we lose a few features by the way. We'll more easily be able to contribute to tsserver after we can have a minimum viable experimental LSP support.
I don't have any major updates; as Ryan mentioned, the work is happening bit by bit, but we are working on it so I've at least labeled the issue as such. One thing that @minestarks mentioned to me is that it would be good to have a channel with implementers who plan to use an LSP server so that we can potentially coordinate and hear more about use-cases. If you're an LSP client implementer, I'd encourage you to just drop a reply here.
I'm not directly an LSP client implementer, but I'm hoping to use tsserver as a language server in https://github.com/apexskier/nova-typescript as a language server for Nova instead of typescript-language-server.
And I am willing to help with any tasks that might help @apexskier achieve that goal because I much prefer Nova and I work all day on build tools for large TypeScript monorepos.
more about use-cases.
I guess we all(lsp client maintainers) have one use-case - we want to access the tsserver functionality via LSP protocol to avoid the need to support multiple protocols.
If you're an LSP client implementer, I'd encourage you to just drop a reply here.
@leungbk and I are maintainers of Emacs LSP client - https://emacs-lsp.github.io
@DanielRosenwasser I'd be interested in being included - I'm the maintainer of typescript-language-server, which uses tsserver internally :)
@joaotavora, the author of eglot, another LSP client for Emacs, may also be interested.
I was asked to comment on this, as ALE implements the tsserver protocol quite thoroughly. I think supporting Language Server Protocol would be good. I would like to make two recommendations.
- Whenever you
npm install typescript, make sure that also installs a language server you can execute from the CLI. - Update Language Server Protocol to support explicit diagnostic requests: microsoft/language-server-protocol#737
Because you always get tsserver in node_modules whenever you install typescript, ALE is able to run the language server automatically and report problems for any project that uses TypeScript. You might have to go out of your way for it not to work automatically.
One thing tsserver does better than LSP servers is that you can control when diagnostics will be sent to the client. I explained more in the issue I linked above. I would miss that feature if tsserver was ever replaced with an LSP server. A common complaint I see from ALE users is that they see errors in their editor when they are just using autocompletion, and that's because LSP servers just send diagnostics whenever they want, often in response to documents changing.
Thanks to all who have commented so far, it's helpful to get context on the various use cases for this, and to learn from the experience of those who have already built LSP adapters. We'll be reviewing how to proceed (admittedly, slowly) while maintaining both compatibility and flexibility... and hopefully have updates to share before long!
@DanielRosenwasser @minestarks feel free to reach out to me in regards to Deno. We have been re-implenenting a lot of the Language Server in TypeScript to provide a Deno Language server and doing similar transforms that VSCode does in Rust. Be more than glad to chat about it. No real challenges, but in some cases there is actually quite a lot of logic (like CodeActions).
is it possible to make a bridge from tsserver to lsp?
is it possible to make a bridge from tsserver to lsp?
That's the purpose of https://github.com/theia-ide/typescript-language-server ; but maintenance, usage and evolution would be much simpler if LSP support is built-in directly in tsserver. Additionally, having tsserver able to talk LSP natively, additionally or alternatively to its own protocol, seems very consistent with the goals of tsserver itself.
@DanielRosenwasser I'd be interested in testing this in gnome-builder (I started looking into a typescript plugin a while back but that hit a dead end when I found out tsserver doesn't support LSP, so I'd love to have another look).
I'm a Vetur maintainer. Vetur is a Vue language support extension in vscode.
https://github.com/vuejs/vetur
The vls is a Vue language server in Vetur. We provide JavaScript/TypeScript features with TypeScript language service.
If typescript can support LSP and enough flexible options, Vetur can use it and reduce many maintenance costs.
In the past, we need to align LSP with TypeScript language service and VSCode.
Hi. Any progress or more concrete plans towards that ?
If typescript can support LSP and enough flexible options, Vetur can use it and reduce many maintenance costs.
Does Vetur actually gain any benefit from an LSP client? When I last contributed to it, Vetur just directly spun up its own TypeScript service instance (as opposed to a server) because it needed to create virtual files for the service.
Hi TypeScript team, any update on this? I'm personally much (!) more helped with a LSP server than any language feature.
Additionally, looking at effort put in other places (language features / vscode itself), I'm a bit worried for an "embrace, extend, and extinguish"? Hopefully utterly unfounded, if so forgive me, an IE5+ survivor speaking here.
Thanks for the work on TS!
If there are concrete plans, we'd love to contribute and push this forward... since otherwise we'll need to do work around this limitation!
Hi. I do not know the architectures discussed in this post, I only understand that I'm stuck to using old versions of Eclipse because tsserver does not use LSP protocol. In the main page of Typescript project I read:
"TypeScript is a language for application-scale JavaScript. TypeScript adds optional types to JavaScript that support tools for large-scale JavaScript applications for any browser, for any host, on any OS. TypeScript compiles to readable, standards-based JavaScript. Try it out at the playground, and stay up to date via our blog and Twitter account."
Can anyone point me out a Javascript IDE using Typescript, that allows "application-scale" developers to surf and jump happily around their application ? I'm ready to dump Eclipse for that.... Well not entirly to be honest, I'm still developing in java.
@MonNomIzNoGoud based on what you said, VSCode would be the best choice. If you really want to have a single IDE for both Java and Javascript, IMO Intellij is the best way to go - it has amazing Java support, and you can install Javascript plugins onto non-community versions of it.
If typescript can support LSP and enough flexible options, Vetur can use it and reduce many maintenance costs.
Does Vetur actually gain any benefit from an LSP client? When I last contributed to it, Vetur just directly spun up its own TypeScript service instance (as opposed to a server) because it needed to create virtual files for the service.
You're right.
But the LSP client will also be based on typescript service.
If he is designed to be replaceable, I think Vetur could also benefit from it.
Step back, Aligning TypeScript service and LSP will also be easy in vetur.
I've been watching this issue for a while, and the discussion is getting a bit weird. As far as I can see, work is in progress for this, and when it's all ready the rest will follow easily.
@VVKot I've stumbled into VSCode some long time ago. It didn't seem close to Eclipse's level but I'll give it another go...
For instance in the following code
(function () { var global = this || window; var _Ctrls = null; _Ctrls = global.Ctrls = { test: function() { ////// }, test2: function() { _Ctrl.test(); } }; })
Asking to Go To Definition when you're on the _Ctrl.test() would only work in JSDT, a dead (?) project.
Also when you just type this in a js file in Eclipse:
$.jqplot.RadarXAxisRenderer.prototype.init = function(options) {}
You automatically have a little green arrow on the left that allows you to go to the method you just overrid in the jqplot project.
VSCode couldn't do this...
@dagadbm So you're the one sabotaging this issue's happy ending, you just want random comments to laugh about. How about doing some actual work, eih ?
You're still more enlightened than myself on the subject, I hardly understand what this post is about, I just wanted to upgrade my Eclipse version: I'm stuck to a 2015 version and we're in 2021. Because the JSDT blokes are gone somewhere.
The problem with open source projects is that key people could disappear for many reasons, leaving dead projects littering Github or other repos.
Everything is getting more complex by the hour instead of getting simpler; frameworks pop-up and explode like mushroom's on Tintin's asteroid.
In my youth we used to crack Commodore 64 games by coding in machine language on a 16 bytes (yes bytes) chunk of memory (after short-circuiting some 2 pins on the parallel port, but of course you knew that). Nowadays you have to setup one billion configuration files or tags in order to make things work. My application got so huge I have to pass hours trying to figure out why I put this or that source code in there.
Anyway, young people, I wish you all the luck in this project, I hope you get it done some day. I feel like a dinosaur in here.
I'm locking this issue for a while and hiding a bunch of comments that are completely off-topic. I'll give the benefit of the doubt that people are just joshing around but let's please keep the tone respectful and on-topic
Hi TypeScript team, thanks for TS 4.4. We saw some work starting on #45347, but not much activity since. What can we expect until 4.5?
We've had personnel changes, and in turn had to reprioritize certain tasks. As a result, we won't see an LSP implementation by 4.5. TypeScript 4.6 may have something, but I think we'll have a better sense of scheduling in a month or two.
Happy to continue to work on it If I may.
We appreciate that - but this is a fairly large work item, and on top of that I think we need to work closely with our editor teams to make sure both sides of the LSP implementation are working correctly. For example, VS or VS Code might implement some specific field of a request in theory, but they might implement it differently, or there may have been some oversight. There are also situations where we need to discuss adding some support for some TypeScript-specific extension that the LSP doesn't specify as part of its core list of request types. For that reason, I think it would be best for having someone on the core team tackle this.
@DanielRosenwasser does that mean your implementation might not be useable in other editors?
@DanielRosenwasser does that mean your implementation might not be useable in other editors?
Not addressed to me, but I can tell you from experience with the Deno language server, just adhering to the LSP protocol is only half the battle. What you fill in is quite complex. There is a lot of logic that currently isn't in tsc. So it doesn't mean it won't be unusable by other editors, but it will and does come with opinions. There is a whole set of them in what is in the TypeScript plugin for vscode that would need to be moved to tsc. So I can totally see the need for tight integration, let alone the need to provide the same thing for VS (which likely has had different opinions on that glue code).
For example, vscode uses typescriptreact for .tsx but other editors use tsx as the language ID. 🤷 So, once it is there for VS/VS Code, there would likely still need to be work with other editors, but that wouldn't be by intent.
@DanielRosenwasser does that mean your implementation might not be useable in other editors?
It's really the same as how TSServer integration works today. We add functionality to it, and we strive not to break clients that aren't aware of the changes. Clients then have to add some functionality if they wish to support a new feature. The same would be true of how we develop for LSP.
@kitsonk @DanielRosenwasser thanks for the insight! It's great to see, that there's something happening behind the scenes :)
@DanielRosenwasser I don't think it's correct to assume same support or even quality expectations between how TSServer would support LSP vs its internal protocol.
The goal and expectation from community about TSServer supporting LSP is to make it more easily usable in other IDEs and editors. VS and VSCode already have a great integration with the tsserver-protocol; would you plan to replace usage of the specific protocal with LSP in the VS/VSCode support? If not and you prefer sticking to the tsserver-protocol for VS/VSCode integration because it's working well, then it means that the integration through LSP in VS/VSCode is really not important and that LSP support in tsserver could be implemented independently of VS/VSCode as it does not target those tools; any other LSP-aware tool can be used for testing. However, if you plan to replace tsserver-protocol by LSP in VS/VSCode on the long run, because it allows better factorization and thus allows to save resources, then it makes sense to start working on the VS/VSCode integration early on, but as you said that would be a major piece of work that would take time to be complete and reach same level of quality as current integration, while I imagine having some relatively simple operations available soon for other IDEs/editors to consume tsserver more directly with LSP would be highly profitable.
I would have expected that community contributions to bring this to TypeScript "core" would be more welcome; particularly as there is already some good part of code available for inclusion (eg https://github.com/typescript-language-server/typescript-language-server )...
@DanielRosenwasser thank you for the clarity and transparency - appreciate the classic dilemma (better handled by core team, but also limited resources on core team).
Somewhat orthogonal to the LSP/tsserver discussion: would there be value in pushing something forward here now that would help someone on the core team later? Or should this really be end-to-end taken by someone on core? Asking in good faith; clearly there's community demand.
Hi TypeScript team, any update on this? It seems nothing happened since Sep 2021, and it's not part of the TS 4.7 Iteration Plan (#48027) or overall roadmap either. Is it the right conclusion it has no priority and we should set our expectations accordingly?
If it ever happens, I hope tsserver plugin API survives as https://github/vuedx/languagetools depends on it.
The sensible thing to do is support tsserver for probably years to come, and LSP in addition to that. That will give all editors and plugin authors plenty of chance to replace their tsserver implementations with LSP. This being added to the spec very recently is of great help: microsoft/language-server-protocol#737
Is it ok to close the issue
and say that LSP support is not planned?
When this issue got traction,
I could not wait for TS 4.5 to arrive with LSP, then 4.6... 4.7.... Now we are at TS 5.2... still no LSP support.
Given how things played out, it looks like this will not be a priority anytime soon.
I've closed issues after years of them being open as a good solution was found, and I have had issues I have never closed because no one has ever solved the problem in years. I fundamentally believe issues should only ever be closed if they are resolved.
For others following, @jakebailey last commented on this topic in #57475, with #59250 and #59905 both seeming to still capture this in their iteration plans 💙.
The current LSP thinking is to slowly onboard calls away from the old protocol onto the new one, so it's not going to be like one day we aren't LSP and one day we are, either.
@jakebailey did you have any thoughts on a rough timeline for support? Are we months or probably years away?
I can't promise anything, but I'm certainly hoping it's not years. This is work I want to do.
The main question I have for you is "why do you want LSP?" What specific problem are you looking to solve by having it implemented?
To be clear, I am not saying it's a bad idea to do, not at all, I want to do it! But, my experience talking to interested parties has mainly found that a switch to LSP will not actually fix any of their problems; this work boils down to tsserver talking in terms of different JSON blobs. It likely will not enable any new functionality, nor is it likely to change tsserver's performance characteristics, cancellation semantics, ability to use a VFS, etc.
Talking for myself, I don't want to use a third party intermediary translation layer (or proxy) for my editor to support tsserver when LSP is supported natively by my editor.
I'm using Nova, which also support LSP (but not tsserver). :(
It would free the maintainers of typescript-language-server from having to maintain the proxy, free downstream from having to maintain packages of the proxy, and users would not have to find a way to install the proxy when they already have typescript installed.
This might be a naive question to ask, and it might not be something the project wants to take on, but would it make sense for typescript to basically embed one of the LSP proxy translation layers for the time being, and then be able to slowly switch out the underlying calls from proxied -> native as that work gets completed?
this work boils down to tsserver talking in terms of different JSON blobs. It likely will not enable any new functionality
The different JSON blobs actually matters a lot. Most of the ecosystem tooling has converged around the LSP spec and provided LSP specific tools to make for an excellent editing experience. tsserver not speaking that spec now requires an entire extra ecosystem of tools around tsserver to make it interact with those editors directly.
Which is a bit funny, considering that's exactly the reason Microsoft created the LSP spec to begin with. It's odd that this Microsoft project would wonder what providing an LSP implementation would actually help with 😉
typescript-language-server helps with that gap, but there's issues with that
- It's not nearly as performant as having this built in
- It hasn't actually collapsed the number of competing tooling and related maintenance costs. In Neovim, there's at least 3 ways to set up completion support (vstls, typescript-tools, typescript-language-server)
- New users getting this set up now have added cognitive load of getting started
In short, I think the benefits are actually pretty clear and at the core of why Microsoft created the LSP specification to begin with
Edit: Follow up
But, my experience talking to interested parties has mainly found that a switch to LSP will not actually fix any of their problems
I'd suggest that the mere existence of typescript-language-server and related tools demonstrate outside parties attempting to solve problems that aren't being acknowledged here. Perhaps speak to the maintainers and users of those tools?
I don't want to use a third party intermediary translation layer (or proxy)
It would free the maintainers of typescript-language-server from having to maintain the proxy, free downstream from having to maintain packages of the proxy, and users would not have to find a way to install the proxy when they already have typescript installed.
The different JSON blobs actually matters a lot.
I'd suggest that the mere existence of
typescript-language-serverand related tools demonstrate outside parties attempting to solve problems that aren't being acknowledged here.
I understand the interop rationale fully (I've worked on three LSP servers before joining the TypeScript team!), so it does not surprise me that everyone's reply is "because interop" or "to not have to have a wrapper". There have been other threads where people have implied that LSP would enable features that it actually wouldn't (e.g. virtual workspaces, embedded languages), so I mainly just wanted to set expectations about how I am personally thinking.
would it make sense for typescript to basically embed one of the LSP proxy translation layers for the time being
This turns into a licensing/CLA question, among other implementation/design constraints.
Which is a bit funny, considering that's exactly the reason Microsoft created the LSP spec to begin with. It's odd that this Microsoft project would wonder what providing an LSP implementation would actually help with
The tsserver protocol predates LSP (and in some ways inspired it), and until recently had some critical tricks that LSP did not have (e.g. pull-ish diagnostics, which are still not implemented in many editors, but are effectively required for editors like VS; TS doesn't have push diagnostics exactly like LSP wants, either). I'm not "pondering" per se; just trying to read the room and again set expectations.
I understand the interop rationale fully (I've worked on three LSP servers before joining the TypeScript team!), so it does not surprise me that everyone's reply is "because interop" or "to not have to have a wrapper".
Right. We know you know. That's why my reply was a bit on the nose - the entire point for us is having a well maintained LSP provider and that's why many of us work on the tsserver wrappers. We understand what LSP support entails here 🤷
The main question I have for you is "why do you want LSP?" What specific problem are you looking to solve by having it implemented?
You can ask "Why does the LSP exist?" and the answer(s) will also apply to your question.
Big update: we're working on LSP, and it's happening over in https://github.com/microsoft/typescript-go as a part of our port to native. There's already a prototype over there.
See: https://devblogs.microsoft.com/typescript/typescript-native-port/
That's incredible. TypeScript and Go. Two of my favorite languages.
Makes me wish I was back at Microsoft. :)
There's already a prototype over there.
Direct link:
- https://github.com/microsoft/typescript-go#running-lsp-prototype
-
Running LSP Prototype
-