pmizio
Reading the "How it works" section, I'm still uncertain what's different from the regular ts lsp?
Was reading: https://github.com/pmizio/typescript-tools.nvim?tab=readme-ov-file#-how-it-works
and I'm still not clear why or how typescript-tools is better than ts_ls.
Any additional insights would be greatly appreciated <3
I have run in to all the problems the README has described for large monorepos (slow, etc), but I don't see how typescript-tools does anything different?
I am by no means an authoritative source on this matter, so grains of salts required; but my understanding is that typescript-tools removes a middle man, eliminating a costly I/O step.
NeoVim ts_ls Tsserver Instance
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ T │ │ │
│ │ │ r │ │ │
│ │ │ a │ │ │
│ │ │ n │ │ │
│ │ │ s │ │ │
│ │ │ l │ │ │
│ │ │ a │ │ │
│ ├───────────▶ t │────────────▶ │
│ │ │ i │ │ │
│ ◀───────────┤ o │◀───────────┤ │
│ │ Request/ │ n │ Request/ │ │
│ │ Response │ │ Response │ │
│ │ IO │ │ IO │ │
│ │ │ │ │ │
└────────────────┘ └────────────────┘ └────────────────┘
The translation done by ts_ls (to translate LSP request to and from tsserver's own dialect) is handled directly in lua within neovim by typescript-tools.
Someone please correct me if my assumptions are wrong.
coc does translation too, and that's supposedly faster than everything. Translation might not be the only factor here.
It might have to do with not blocking the process. This is a separate plugin and has access to nvim apis. Specifically, the handlers are wrapped in vim.schedule to avoid blocking the event loop. coc achieves the same thing by being a separate process. ts_ls, vtsls are just cli programs the lsp talks to directly, so it might not be as efficient.
Another possibility is the lua plugin is being pre-compiled and runs faster than node apps. 🤷♂️
Maybe the ultimate TS lsp would be:
nvim -> lua plugin -> LSP translator in rust/go -> tsserver
The ultimate TS LSP would be nvim -> tsserver but we've got what we've got :(
When I setup typescript-tools.nvim plugin, why the buffer was attached to both ts_ls and typescript-tools? and I can't even filter out some diagnostics.
When I setup typescript-tools.nvim plugin, why the buffer was attached to both
ts_lsandtypescript-tools? and I can't even filter out some diagnostics.
If you set up with mason lspconfig 2.0+, when you install ts_ls through Mason, the Mason-lspconfig will automatically call vim.lsp.enable(ts_ls) which trigger ts_ls for you.
Simple solution is just to exclude ts_ls from mason-lspconfig
