diagnostic-languageserver VS typescript-language-server

I'm not using the rust-analyzer plugin actually. I'm using the system installed rust-analyzer and diagnostic-language-server which integrates it with vim. Is there a flag or something to make rust-analyzer return clippy results as well?

For those who use diagnostic-languageserver, this plugin provides a list of pre-defined configurations for you to use without the hassle to figure out the config on your own. Making it easier to integrate with less code.

So reading through everyones suggestions it seems like diagnosticls is the way to go. Looks like this is the official neovim solution https://github.com/iamcco/diagnostic-languageserver formerly https://github.com/nvim-lua/diagnostic-nvim

Does anybody have such? Maybe you could share your experience? I use coc.nvim. My eyes fell on these 3 tools. The first one is language server and it has coc extensions coc-sh. But others are not so I am not sure which vim plugin should I use to hook them up: besides diagnostic-languageserver there are syntastic and neomake - bash-language-server - shellcheck - shfmt

>https://github.com/iamcco/diagnostic-languageserver

I also added 2 experimental features designed to reduce the amount of boilerplate required to get a functional TypeScript development environment. diagnostic-languageserver and efm-langserver are powerful, but they can be tough to set up for new users, so I wanted to implement low-config, out-of-the-box alternatives for formatting and linting:

I’ve personally never gotten efm to work at all, and I never figured out why (much like your situation). I use diagnostic-languageserver, which worked like a charm the first time. I’ve heard some users say it’s slower (TypeScript versus Go), but I’ve never had any speed issues.

Aside from that, the biggest difference versus CoC is the ecosystem, which affects setup / tweaking time and code actions. I was able to set up ESLint diagnostics with diagnostic-languageserver, but it doesn't integrate with typescript-language-server at all, and I haven't been able to set up ESLint fixing + Prettier, either, All of that is trivial with CoC.

Some LSP like diagnostic language server and efm language server do that for you. However, you will need to do some manual setup yourself for pylama to work with them, unfortunately, I don't see either of them have an example for pylama so you will have to write one yourself for those LSP servers.

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...

I would like to use svelte language server when working on +page.server.ts files and not the typescript language server.

[[language]] name = "python" roots = ["pyproject.toml"] formatter = { command = "black", args = ["--quiet", "-"] } language-server = { command = "pyright-langserver", args = ["--stdio"] } config = {} auto-format = true [[language]] name = "rust" auto-format = true # [[language]] # name = "typescript" # auto-format = true # formatter = { command = "prettier", args = ["--parser", "typescript"]} # # pass format options according to https://github.com/typescript-language-server/typescript-language-server#workspacedidchangeconfiguration omitting the "[language].format." prefix. # config = { format = { "semicolons" = "insert", "insertSpaceBeforeFunctionParenthesis" = true } } [[language]] name = "tsx" formatter = { command = 'prettier', args = ["--parser", "typescript"] } auto-format = true [[language]] name = "javascript" auto-format = true formatter = { command = 'npx', args = ["prettier", "--config", ".prettierrc", "--parser", "javascript"] } # formatter = { command = "prettier", args = ["--parser", "javascript"]} [[language]] name = "css" formatter = { command = 'prettier', args = ["--parser", "css"] } [[language]] name = "markdown" # https://github.com/executablebooks/mdformat formatter = { command = "mdformat", args = ["-"] } [[language]] name = "json" formatter = { command = "prettier", args = ["--parser", "json"] } [[language]] name = "toml" auto-format = true # https://github.com/bd82/toml-tools/tree/master/packages/prettier-plugin-toml formatter = { command = "prettier", args = ["--parser", "toml"] } [[language]] name = "yaml" indent = { tab-width = 2, unit = " " } formatter = { command = "prettier", args = ["--parser", "yaml"] } [[language]] name = "astro" scope = "source.astro" injection-regex = "astro" file-types = ["astro"] roots = ["package.json", "astro.config.mjs"] language-server = { command = "astro-ls", args = ["--stdio"] } config = { "typescript" = { serverPath = "/Users/matteostara/.nvm/versions/node/v18.16.0/bin/typescript-language-server" }, "environment" = "node" }

Depending on the language server version, you may be running into https://github.com/typescript-language-server/typescript-language-server/issues/631. I temporarily fixed it for me by simply sticking with an old enough server build, though judging by the latest typescript-language-server commits a very recent build from master should also work

Before, I was using typescript-language-server as it is LSP compliant but it was slow and lacks the features of what VSCode's implementation has, like extracting functions, constants, types into interfaces or alias and single imports. Auto-completion was also not very predictive as sometimes it works and sometimes it doesn't. For instance, I was having trouble getting it to auto-complete common attributes like className or href in JSX projects. It could be that I may be doing something wrong but didn't find any solution on how to get it properly working.

Then this is highly likely issue of typescript-language-server. You might consider opening an issue for it.