dotfiles VS typescript-language-server

I haven't pushed latest changes to my repo yet but you can just add it to the lsp servers list and disable typescript.nvim plugin and it should work just fine. (Make sure you have vtsls installed or you could just uncomment this line and it'll install it automatically).

Over the last little while, I’ve been working more actively with open-source projects, especially ones related to the TypeScript ecosystem. In my previous contributions, I focused on tools that are used behind the scenes by editors, like language servers (typescript-language-server), which help with things such as error reporting, code navigation, and auto completion. That experience pushed me outside my comfort zone, but it also helped me understand how large developer tools are structured and maintained.

I recently finished an open-source contribution that I’m actually really proud of. This time, I worked on the typescript-language-server project. I wanted to challenge myself with something more complex than what I normally do, and I came across Issue #956, which asked to support a new tsserver feature called --canUseWatchEvents.

I'd almost given up on finding "the right" solution. Everywhere I looked, others had "solved" the issue in different ways: they were using the vtsls TypeScript LSP wrapper instead of ts_ls, or they were using coc.nvim, or the now-archived null-ls.nvim. But nowhere could I simply find a reliable configuration for a Vue language server configured natively in NeoVim.

typescript-language-server

Besides the features TypeScript itself proposed, the most important thing it brought to the community was the ability to create cool features around this compiler that enhance the developer experience and productivity. Tools like tsserver, pretty ts errors, and many others are actively improving the ecosystem for both JavaScript and TypeScript writers.

Sometimes a language server can support multiple filetypes. An example of this is tsserver, the language server for javascript and typescript. In this case a filetype plugin can still work but there is an easier way to go about it.

in this way the ts server can detect and parse the component from the microfronent, thanks to monorepos!

That was interesting, thanks for pointing it out

I was tremendously sad to see that the Typescript Language Server wasn't owned by Microsoft <https://microsoft.github.io/language-server-protocol/impleme...>, since if there was any sanity in the world a spec bump would travel with a reference implementation showing how they envision such a thing being used

But, I found that the Typescript Language Server that they did list does indeed have a semantic-tokens module in it, although it's much shorter than I would have expected from reading that section in the spec: https://github.com/typescript-language-server/typescript-lan...