They could have also contributed to the effort. You can also add types to monaco typescript. I don’t see a need for a Deno specific LSP, am I missing something?
The biggest deal difference between the Deno LSP and Typescript sort-of-LSP in my experience is around the import model. Typescript has a bunch of "module resolution" modes based on various combinations of browser, bundler, and/or Node. For various reasons the Deno LSP is the only encoding of the Deno "module resolution' and upstream Typescript doesn't have a "denoX" set of "module resolution" options.
The second biggest deal is that the Deno LSP also includes a full linter, versus for the full experience the Typescript not-quite-LSP is often paired with the ESLint VS Code extension and a large eslint install.
Deno's LSP is also sometimes preferred for being a single Rust binary that runs quicker than Typescript's not-quite-LSP (plus or minus ESLint's non-LSP). It may be interesting to see how Golang Typescript's real-LSP fares in comparison in a future version.
Ah interesting, Yes i see what you’re saying regarding eslint and didn’t consider that. I’m a big of newer linters with better perf but none match the depth currently with eslint. Will keep an eye out on deno lsp!
WorldMaker|5 months ago
The second biggest deal is that the Deno LSP also includes a full linter, versus for the full experience the Typescript not-quite-LSP is often paired with the ESLint VS Code extension and a large eslint install.
Deno's LSP is also sometimes preferred for being a single Rust binary that runs quicker than Typescript's not-quite-LSP (plus or minus ESLint's non-LSP). It may be interesting to see how Golang Typescript's real-LSP fares in comparison in a future version.
gvkhna|5 months ago