[brundolf]

Thanks- I should probably actually file bug reports :)

I am curious though: why roll your own? It seems like the only real differences are a) URLs/file extensions in the module names, and b) some type declarations for the system APIs (which I'd think just come down to some .d.ts files, not custom LSP logic). Microsoft's TypeScript language server is a wonder of engineering, and I doubt any small independent team would ever be able to go toe-to-toe with it. Seems like a waste to forego that if there's any possibility of utilizing it. A minimal fork maybe, if nothing else?

[lucacasonato]

TypeScript does not actually have a native language server. TSC is just directly shoehorned into VS Code. It is very difficult to extend (we tried with the 1.x and 2.x branch of our extension). We needed to do a lot of trickery to get TSC to do what we want, and even then it would not always work. That solution also only worked on VS Code. Our new LSP works on all editors with LSP support. We are hoping that in the coming few weeks / months the Deno LSP will be just as featureful as TSC + Node in VS Code, and way more performant. We still have some ways to go, but we are slowly getting there.

[paxys]

This is only partially true. TypeScript does have tsserver built in, which is where the language server design originated from (just with a slightly different API). The VS Code TypeScript integration is a layer around that, not a custom implementation. There are also a couple other TypeScript language servers out there (which again simply wrap tsserver and translate the APIs) which work great.

[brundolf]

Ah gotcha, that's unfortunate that they integrated it directly, though it explains a lot.

Well I'm glad to hear it's a priority. Best of luck, and I'll try to check in periodically and see how things are coming along! I would very much like to see this project succeed :)

[wperron]

There's a couple of reasons. Internally, there's quite a few things that we do in Rust that aren't actually taken care of by TypeScript -- Having our own LSP allows us to connect those bits (like the module graph resolver for example) directly to the internals of Deno, in-sync with the Deno version you have installed.

Deno also does more stuff than just providing Type definitions, embedding TypeScript and doing module resolution; it's a complete toolset -- there's things that we can cover having our own LSP that the TypeScript LSP can't. Linting, formatting, testing etc.