Deprecating builtins with unmaintained upstream or native LSP replacement
mochaaP opened this issue · comments
Related projects:
- https://github.com/nvimtools/none-ls-extras.nvim
- https://github.com/gbprod/none-ls-php.nvim
- https://github.com/gbprod/none-ls-shellcheck.nvim
- https://github.com/gbprod/none-ls-luacheck.nvim
- https://github.com/gbprod/none-ls-psalm.nvim
- https://github.com/gbprod/none-ls-ecs.nvim
I'm thinking of cleaning up some builtins with the following criteria:
- Unmaintained (> 1y) or deprecated by upstream with better and widely adopted replacement available (e.g. JSHint, Luacheck)
- Fully overlapped feature (markdownlint, markdownlint-cli2, mdl)
- Native LSP available (e.g. ESLint, Biome, Taplo, tsc)
Planned to remove (will keep updating):
edit history → #58 (comment)
deleted: code_actions/eslint.lua (use eslint-language-server / available in none-ls-extras.nvim)
deleted: code_actions/eslint_d.lua (use eslint-language-server / available in none-ls-extras.nvim)
deleted: code_actions/ltrs.lua (use ltex-ls)
deleted: code_actions/shellcheck.lua (use bashls / available in gbprod/none-ls-shellcheck.nvim)
deleted: code_actions/xo.lua (use eslint-language-server)
deleted: diagnostics/bandit.lua (use ruff)
deleted: diagnostics/chktex.lua (use texlab)
deleted: diagnostics/clang_check.lua (use clangd)
deleted: diagnostics/cpplint.lua (use clangd / available in none-ls-extras.nvim)
deleted: diagnostics/curlylint.lua
deleted: diagnostics/deno_lint.lua (use deno lsp)
deleted: diagnostics/eslint.lua (use eslint-language-server)
deleted: diagnostics/eslint_d.lua (use eslint-language-server)
deleted: diagnostics/flake8.lua (use ruff / available in none-ls-extras.nvim)
deleted: diagnostics/gospel.lua
deleted: diagnostics/jshint.lua (use eslint-language-server)
deleted: diagnostics/jsonlint.lua (use jsonls)
deleted: diagnostics/luacheck.lua (use selene / available in gbprod/none-ls-luacheck.nvim)
deleted: diagnostics/misspell.lua
deleted: diagnostics/php.lua (available in gbprod/none-ls-php.nvim)
deleted: diagnostics/protoc_gen_lint.lua (use buf)
deleted: diagnostics/puglint.lua
deleted: diagnostics/psalm.lua (use psalm lsp / available in gbprod/none-ls-psalm.nvim)
deleted: diagnostics/puppet_lint.lua
deleted: diagnostics/pycodestyle.lua (use ruff)
deleted: diagnostics/pydocstyle.lua (use ruff)
deleted: diagnostics/pylama.lua (use ruff)
deleted: diagnostics/pyproject_flake8.lua (use ruff)
deleted: diagnostics/ruff.lua (use ruff lsp)
deleted: diagnostics/semistandardjs.lua (use eslint-language-server)
deleted: diagnostics/shellcheck.lua (use bashls / available in gbprod/none-ls-shellcheck.nvim)
deleted: diagnostics/standardjs.lua (use eslint-language-server)
deleted: diagnostics/standardrb.lua (use standardrb lsp)
deleted: diagnostics/tsc.lua (use tsserver)
deleted: diagnostics/typos.lua (use typos-lsp)
deleted: diagnostics/vulture.lua (use ruff)
deleted: diagnostics/xo.lua (use eslint-language-server)
deleted: formatting/autoflake.lua (use ruff)
deleted: formatting/autopep8.lua (use ruff)
deleted: formatting/beautysh.lua (use shfmt)
deleted: formatting/brittany.lua (use haskell-language-server)
deleted: formatting/cabal_fmt.lua (use haskell-language-server)
deleted: formatting/deno_fmt.lua (use deno lsp)
deleted: formatting/docformatter.lua (use ruff)
deleted: formatting/dprint.lua (use dprint lsp)
deleted: formatting/dtsfmt.lua (upstream is missing)
deleted: formatting/eslint.lua (use eslint-language-server)
deleted: formatting/eslint_d.lua (use eslint-language-server)
deleted: formatting/fixjson.lua (use jsonls)
deleted: formatting/fourmolu.lua (use haskell-language-server)
deleted: formatting/htmlbeautifier.lua (use tidy)
deleted: formatting/jq.lua (use jsonls)
deleted: formatting/json_tool.lua (use jsonls)
deleted: formatting/jsonnetfmt.lua (use jsonnet-language-server)
deleted: formatting/latexindent.lua (use texlab / available in none-ls-extras.nvim)
deleted: formatting/lua_format.lua (use stylua)
deleted: formatting/markdown_toc.lua (use marksman)
deleted: formatting/perlimports.lua (use PerlNavigator)
deleted: formatting/perltidy.lua (use PerlNavigator)
deleted: formatting/puppet_lint.lua
deleted: formatting/pyflyby.lua (use ruff)
deleted: formatting/reorder_python_imports.lua (use ruff, isort or usort)
deleted: formatting/ruff.lua (use ruff lsp)
deleted: formatting/ruff_format.lua (use ruff lsp)
deleted: formatting/rustfmt.lua (use rust-analyzer)
deleted: formatting/semistandardjs.lua (use eslint-language-server)
deleted: formatting/standardjs.lua (use eslint-language-server)
deleted: formatting/standardrb.lua (use standardrb lsp)
deleted: formatting/standardts.lua (use eslint-language-server)
deleted: formatting/stylish_haskell.lua (use haskell-language-server)
deleted: formatting/taplo.lua (use taplo lsp)
deleted: formatting/templ.lua (use templ lsp)
deleted: formatting/terrafmt.lua
deleted: formatting/trim_newlines.lua (use editorconfig)
deleted: formatting/trim_whitespace.lua (use editorconfig)
deleted: formatting/vfmt.lua (use vls)
deleted: formatting/xmlformat.lua (use lemminx)
deleted: formatting/xmllint.lua (use lemminx)
deleted: formatting/xq.lua (use lemminx)
deleted: formatting/yq.lua (use yamlls)
deleted: formatting/zigfmt.lua (use zls)
I support this. Maybe create a 'legacy' branch so people can easily use an old version of the plugin if they rely on something that is due to be removed?
This won't happen very soon without further notice. I guess we could add a notice on startup if users are using any of the deprecated builtins, and finally remove them, for likely 1 to 2 months later?
Also, users could just copy & paste the builtins they use into their config, so I don't feel the very need to maintain a separate branch.
. I guess we could add a notice on startup if users are using any of the deprecated builtins
This just reminds me of a post on reddit
Hi, for the unmaintained ones, what is the main motivation to remove them? Is it just out of caution, that they might break? I have contributed two diagnostics parsers (checkstyle and pmd), which I have last touched over two years ago, but they should still work. Outright removing them might not be the best idea.
for the unmaintained ones
It's just for the upstream abandoned projects. pmd and checkstyle are all fine, since upstream actively maintains them :)
Ah OK gotcha. I first understood that whether or not the builtins themselves are maintained or not is the deciding factor. I simply misread. In that case this sounds like a sensible idea. Carry on. 😀
(moved to the issue body)
Please don't remove yapf, pyink, flake8, black, isort, pep8, etc (anything related to python/ruff). These are all still popular and widely used --- IMHO Ruff is still not mature enough to replace all the formatters.
I also find that the list you suggest is quite aggressive. Not only for python but for other langs. The removal/deprecation should be done in more like a opt-in manner rather than opt-out manner.
Also I think it'd be great to main the current, up-to-date list of the plan in the body (i.e. at the very top) of this issue because comments in the middle will get easily out of attention?
Please don't remove yapf, pyink, flake8, black, isort, pep8, etc (anything related to python/ruff). These are all still popular and widely used --- IMHO Ruff is still not mature enough to replace all the formatters.
See the FAQ here. I tried not to break things if there are a significant number of rules not implemented.
I also find that the list you suggest is quite aggressive. Not only for python for other langs. The removal/deprecation should be done in more like a opt-in manner rather than opt-out manner.
The change may start rolling out on a separate branch first. I look forward to merging that into master in 1–2 years.
The removals are mostly due to the overhead on executing binaries, especially on Windows with EDR activated that hooks into LaunchProcess. Furthermore, most recommendations are using the same underlying engine.
Also I think it'd be great to main the current, up-to-date list of the plan in the body (i.e. at the very top) of this issue because comments in the middle will get easily out of attention?
I will put a link to this comment (to preserve edit history).
See the FAQ here. I tried not to break things if there are a significant number of rules not implemented.
That's ruff's goal, but at this point not really. Ruff is a good diagnostics tool so for diagnostics maybe yes, but as a formatter I don't think it's mature enough yet. Your list includes more than what Ruff is currently capable of. For flake8 I would say it's OK (although very controversial) to remove, but ruff is never going to be the 100% exactly the same with other formatters that are still widely used in many projects, it can't be a replacement. For instance: isort, black, yapf, etc. which are all clear NO. Ruff-formatter aims to be as similar as black, although it isn't ATM, and black is not the only formatter in the Python community.
https://docs.astral.sh/ruff/faq/#how-does-ruffs-import-sorting-compare-to-isort.
https://docs.astral.sh/ruff/faq/#is-the-ruff-linter-compatible-with-black
Fair point, thanks. I've restored isort, black, yapf, pyink from the list.
I never used flake8 and have not looked into ruff, but removing a tool because there is an alternative tool can be problematic. You don't always have the choice of what tool to use. So if ruff doesn't do exactly the same thing and uses the same configuration files it's not a good replacement. Same might be the case for other tools.
@mochaaP Thanks for considering the suggetsion!
but removing a tool because there is an alternative tool can be problematic.
+1, I second this point by @sblask. None-ls.nvim should be deprecating things only if the project is abandoned (or more precisely, users are also leaving and abandoning it) and good modern alternatives are available. There could be inactive, not-so-quite-updated tools that can still work great and be used in many projects. None-ls.nvim is a collection of tools that users can pick and start using out-of-box. If a tool that's already available in our curated list is abandoned, it's provided as-is, hence no maintenance cost added.
Since this project is a community effort, the most important factor to take into consideration is your feedback. Thank you all for caring about this project!
dprint also has its native language server: dprint/dprint#803
@g-plane: updated, thanks.
Hi, do you plan to remove the tools listed above also from mason.nvim and mason-tool-installer?
@williamboman @WhoIsSethDaniel
Or only for the recipes defined in none-ls?
Hi, do you plan to remove the tools listed above also from mason.nvim and mason-tool-installer? @williamboman @WhoIsSethDaniel
Or only for the recipes defined in none-ls?
There's no change to mason-tool-installer. It will continue to support whatever mason can download.
rustfmt shouldn't be deprecated. rust-analyzer won't do anything about formatting, and the rust-analyzer config in lspconfig has nothing about rustfmt or formatting.
👌
Hi!
I think it's a good thing to remove obsolete/unmaintained tools or tools with better alternative (LSP) !
Anyway, I still using the php builtin (mainly because I sometimes don't want to use a LSP server and because it's faster) and I've tried to create a none-ls plugin here : https://github.com/gbprod/none-ls-php.nvim. I think it could be a good alternative for some tools that none-ls's core team does'nt want to maintain, maybe it could be documented or liked somewhere ?
I'll probably do the same with luacheck that I'm still using.
Thanks for your work !
Hi @gbprod,
Your project was already featured here! ;)
Why is typos on the list? (It is actively maintained (or am I missing something))
@altermo:
https://github.com/neovim/nvim-lspconfig/tree/master/lua/lspconfig/server_configurations/typos_lsp.lua typos-lsp is available from nvim-lspconfig ;)
rustfmt shouldn't be deprecated. rust-analyzer won't do anything about formatting, and the rust-analyzer config in lspconfig has nothing about rustfmt or formatting.
You can definitely install rustfmt through rustup but how do you link the rustup install with none-ls? For now I still install rustfmt through mason-null-ls.
https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/caps.rs#L71
https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/handlers/request.rs#L1915
I suppose rustfmt is actually included in rust-analyzer? Correct me if I'm wrong.
FYI, I use psalm with none-ls but I know there is a LSP alternative, I don't know if we should deprecate this builtin or not 😅 but if you do, I can create another plugin ;)
If I disable none-ls and enable rust-analyzer with lspconfig only, it won't format. Not sure whether my config is wrong or there's a bug in lspconfig.
My config is wrong, sorry.
Yeah, I missed that. You can go ahead and create another plugin! :)
My config is wrong, sorry.
Can you share what was wrong with your config then, please? I have rust-analyzer setup as well but it doesn't format if I don't setup rustfmt through mason-null-ls and none-ls. I looked into the settings and I saw rust-analyzer actually supports formatting but I couldn't make it work.
@Nargonath You need to configure like this:
local function format_on_save(client, bufnr)
vim.api.nvim_clear_autocmds({ group = augroup, buffer = bufnr })
vim.api.nvim_create_autocmd("BufWritePre", {
group = augroup,
buffer = bufnr,
callback = function()
vim.lsp.buf.format({ bufnr = bufnr })
end,
})
end
local lspconfig = require("lspconfig")
lspconfig.rust_analyzer.setup({
on_attach = format_on_save,
})If you've already configured the on_attach with something else, for example, I'm using "lspstatus", you can configure like this:
local function format_on_save(client, bufnr)
vim.api.nvim_clear_autocmds({ group = augroup, buffer = bufnr })
vim.api.nvim_create_autocmd("BufWritePre", {
group = augroup,
buffer = bufnr,
callback = function()
vim.lsp.buf.format({ bufnr = bufnr })
end,
})
end
local lspconfig = require("lspconfig")
lspconfig.rust_analyzer.setup({
on_attach = lspconfig.util.add_hook_after(format_on_save, require("lsp-status").on_attach),
})Hope it helps.
There's an official Ruff language server, so we can deprecate Ruff as well:
Thanks @g-plane for sharing your setup. It's definitely helpful as I do the same but in a different way and I think I understand why it's not working now. I use lazy.nvim for my plugins management. Here is what I have on my side:
-- CONFIG_ROUTE/lua/plugins/lspconfig.lua
local augroupFormat = vim.api.nvim_create_augroup("LspFormatting", {})
return {
{
"williamboman/mason.nvim",
config = true,
},
{
"williamboman/mason-lspconfig.nvim",
opts = {
ensure_installed = {
"tsserver",
"dockerls",
"bashls",
"terraformls",
"tailwindcss",
"rust_analyzer",
"taplo",
"graphql",
},
handlers = {
function(server_name)
local settings = {
common = {
capabilities = require("cmp_nvim_lsp").default_capabilities(),
flags = {
debounce_text_changes = 150,
},
},
tsserver = {
settings = {
typescript = {
format = {
enable = false,
},
},
javascript = {
format = {
enable = false,
},
},
},
},
}
require("lspconfig")[server_name].setup(
vim.tbl_deep_extend("force", settings.common, settings[server_name] or {})
)
end,
},
},
},
{
"nvimtools/none-ls.nvim",
opts = {
on_attach = function(client, bufnr)
if client.supports_method("textDocument/formatting") then
vim.api.nvim_clear_autocmds({ group = augroupFormat, buffer = bufnr })
vim.api.nvim_create_autocmd("BufWritePre", {
group = augroupFormat,
buffer = bufnr,
callback = function()
vim.lsp.buf.format({ async = false })
end,
})
end
end,
},
dependencies = { "nvim-lua/plenary.nvim", "neovim/nvim-lspconfig" },
},
-- other dependencies like mason-null-ls and nvim-lspconfig
}Initially in my setup, only tools registered through none-ls were used for formatting so it was working for me to declare the on_attach function (similar to what you have) through none-ls. The problem is that rust_analyzer is handled through nvim-lspconfig (with help of mason and mason-lspconfig) so it doesn't get the on_attach function which is why the formatting doesn't work with it. Once I installed rustfmt through mason-null-ls then my current on_attach setup work and I could use it but since this usage gets deprecated it's not an acceptable solution. Setting the same on_attach function in my handlers setup code in mason-lspconfig should fix it. I'll report once it's fixed. I decided to share it since it might help somebody else.
Doing what I mentioned above fixed my problem. Thanks @g-plane for your insight. 🙏
Doing what I mentioned above fixed my problem. Thanks @g-plane for your insight. 🙏
found any way to use the rustfmt of system instead of the one from mason?
@niksingh710 Yes I gave the solution above. Basically assigning an on_attach handler (same as the one I shared) on your rust_analyzer LSP will allow enabling formatting through rust_analyzer instead of mason rustfmt installation.
@niksingh710 Yes I gave the solution above. Basically assigning an
on_attachhandler (same as the one I shared) on yourrust_analyzerLSP will allow enabling formatting throughrust_analyzerinstead ofmasonrustfmtinstallation.
means currently rust_analyzer not having any way to format?
as i don't see any config option to enable for formatting.
@niksingh710 You're right. There isn't a specific options like format: true or something like that. It's rather a matter of calling the vim.lsp.buf.format() function that will send a formatting command to the LSP. If the LSP supports the formatting command then it will work. You can find an example in rust_analyzer docs: https://rust-analyzer.github.io/manual.html#nvim-lsp.
My own config if you're curious
local augroupFormat = vim.api.nvim_create_augroup("LspFormatting", {})
local formattingOnAttach = function(client, bufnr)
if client.supports_method("textDocument/formatting") then
vim.api.nvim_clear_autocmds({ group = augroupFormat, buffer = bufnr })
vim.api.nvim_create_autocmd("BufWritePre", {
group = augroupFormat,
buffer = bufnr,
callback = function()
vim.lsp.buf.format({ async = false })
end,
})
end
end
return {
{
"williamboman/mason.nvim",
config = true
},
{
"williamboman/mason-lspconfig.nvim",
opts = {
ensure_installed = {
"tsserver",
"dockerls",
"bashls",
"terraformls",
"tailwindcss",
"rust_analyzer",
"taplo",
"graphql",
},
handlers = {
function(server_name)
local settings = {
common = {
capabilities = require("cmp_nvim_lsp").default_capabilities(),
flags = {
debounce_text_changes = 150,
},
},
rust_analyzer = {
on_attach = formattingOnAttach,
},
}
require("lspconfig")[server_name].setup(
vim.tbl_deep_extend("force", settings.common, settings[server_name] or {})
)
end,
},
},
},
-- other plugins like none-ls, mason-null-ls
}@Nargonath according to ur config also rustfmt required to be installed by mason na?
As mine is quite similar to ur's I just don't prefer auto formatting.
Instead, I like auto save and I format it manually. (Much predicted behavior for me 😅)
@niksingh710 Why do you say that rustfmt is required to be installed by mason? I'm not sure whether rust-analyzer has rustfmt shipped with it or if it needs a globally available rustfmt binary. I do have it installed with rustup component add rustfmt though. I should try to remove it and see if it still works.
On my side I like autoformat on save that's why I added the autocmd. If you don't want it to happen automatically, you can bind vim.lsp.buf.format to a keymap instead and trigger it when you want.
@Nargonath Mason gives deprecated warning for rustfmt.
if i install rustfmt via rustup then lsp format fails to format but if i install it via mason it works.
rn i have it by both but in neovim it only works if i have it through Mason. (so the deprecated warning kindda bothers me)
Please, don't deprecate shellcheck as bash-ls is 1) too heavy (requires nodejs) and 2) a bash LSP, so it does not support any other POSIX-compatible shell and cannot enforce POSIX compatibility
@niksingh710 I had the same problem as you before when I didn't add the on_attach that I shared in my previous post. If it still doesn't work for you then perhaps you didn't pass the on_attach properly IMO.
Please, don't deprecate
shellcheckasbash-lsis 1) too heavy (requires nodejs) and 2) a bash LSP, so it does not support any other POSIX-compatible shell and cannot enforce POSIX compatibility
(1) makes sense, but I tested (2) and bash-ls reports POSIX-sh violations correctly when using the right shebang, since it also uses shellcheck if it's installed.
I roughly reviewed the code of bash-ls, it's essentially just tree-sitter + shellcheck + explainshell. How about creating a separate plugin to include all these features + none-ls.nvim integration in a package, so people could have fewer reasons to depend on node?
I will keep the shellcheck builtin in the meantime.
edit: I forgot https://github.com/gbprod/none-ls-shellcheck.nvim exists. Please use that instead.
also cc @gbprod on the last one: do you want to take this?
@niksingh710 I had the same problem as you before when I didn't add the
on_attachthat I shared in my previous post. If it still doesn't work for you then perhaps you didn't pass theon_attachproperly IMO.
ig i have implemented on_attach correctly but the also if you have time and can look at my config
@niksingh710 I quickly looked at your config but it's not easily identifiable what's wrong with it. Your organization is not that straightforward. IMO you should strip everything and simplify your neovim/lspconfig config as much as you can to make it work. It might help you understand what's going on and then apply your findings to your real config.
also cc @gbprod on the last one: do you want to take this?
You're talking about explainshell? I'm not using this tool currently and I prefer (for the moment) only create plugins for tools that I actually use 😅
no worries 😁 btw thank you for the efforts!
I had a thought about this the other day - with such a drastic change coming to the plugin. Would it be worth updating the name internally to none-ls from null-ls at the same time? Feels like if there's ever gonna be time to do it, this is it.
I'd like to pay tribute to the original author's efforts and keep the name as-is, since this is not an overall breaking change on the interface level. :)
This probably will never happen without a huge refactor (like something that could be a major version bump in a semver project), or until I changed my mind?
Can't argue with that I suppose! It's nice to call back to the projects roots.
How exactly do you use clangd instead of clang-format?
Since clangd uses https://github.com/llvm/llvm-project/tree/main/clang/lib/Format (clang-format's underlying logic), you can just configure it in lspconfig / clangd_extensions.nvim and it should work ootb.
you can just configure it in lspconfig / clangd_extensions.nvim and it should work ootb.
@mochaaP How?
Also I have the same question for beautysh, the recommendation is to use bashls but I don't understand how.
See the docs of nvim-lspconfig, please:
https://github.com/neovim/nvim-lspconfig/blob/master/doc/server_configurations.md
I moved from haskell-language-server to fourmolu using null-ls just a few days ago because things just don't work as they should with haskell-language-server. Specifically because it did not respect fourmolu.yaml config in project root. Haskell tooling always has these kind of gotchas, it felt nice to be able to opt-out of that feature of hls and just use fourmolu on its own.
Here is my new config to add custom fourmolu source for anyone else needing it:
local null_ls = require("null-ls")
local my = {
formatting = {
-- fourmolu builtin source got deprecated. https://github.com/nvimtools/none-ls.nvim/issues/58
fourmolu = {
name = "custom-fourmolu",
method = null_ls.methods.FORMATTING,
filetypes = { "haskell" },
meta = {
url = "https://hackage.haskell.org/package/fourmolu",
description = "Fourmolu is a formatter for Haskell source code.",
},
generator = require("null-ls.helpers").formatter_factory({
command = "fourmolu",
args = { "--stdin-input-file", "$FILENAME" },
to_stdin = true,
}),
}
},
}
null_ls.setup({
sources = {
my.formatting.fourmolu
},
})
bashls doesn't provide same code action that is provided by shellcheck builtin (disabling specific warning)
I just got message about autopep8 being depreciated. Use ruff. I switched to ruff, and I got now some message - ruff gonna be depreciated. What did I supposed to use for python formatting?
@mochaaP bashls doesn't seem to have formatting capabilities to replace beautysh
@JoseConseco:
You shall use ruff's lsp server.
bashlsdoesn't seem to have formatting capabilities to replacebeautysh
Good catch there, shfmt is the right one to use. Sorry for the confusion!
During the migration from clang-format to clangd I found a problem, the --style flag in clang-format doesn't work correctly in clangd (use --fallback-style in clangd), I found this in the clangd issue and it's still open now, has anyone else encountered the same problem as I have?
@JoseConseco: You shall use ruff's lsp server.
I see only:
diagnostics.ruff - depreciated
formatting.ruff - depreciated
formatting.ruff_format - depreciated
I cant find build-in config for 'ruff lsp' . It does not exist yet?
I can see in ruff-lsp info about ussing it with nvim-lspconfig . So I guess this is how we should setup formatting now
bashlsdoesn't provide the same code action that is provided byshellcheckbuiltin (disabling specific warning)
The syntax to disable shellcheck rules is the same. You could create a PR or issue to bashls: (https://github.com/bash-lsp/bash-language-server/blob/afd0d82c5a0a3cbedef8098b8944d9b01c47657e/server/src/shellcheck/index.ts#L239) if you'd like to.
@JoseConseco:
You need to configure the native LSP client, either using lspconfig or manually.
During the migration from clang-format to clangd I found a problem, the
--styleflag in clang-format doesn't work correctly in clangd (use--fallback-stylein clangd), I found this in the clangd issue and it's still open now, has anyone else encountered the same problem as I have?
Is placing a clangd configuration file at $XDG_CONFIG_HOME/clangd/config.yaml viable for you? (https://clangd.llvm.org/config#files)
Hey, I know this has been said a few times here, but in general it seems like very bad practice to remove tools that are not unmaintained but the developers here are simply pushing a different tool (i.e. use LSP over linters). I don't always have the choice for what tools to use in a project and it is dictated by groups/project maintainers/company/etc. This becomes important when projects ship with configuration files for tools and expect you to use them for their code bases. none-ls is there to provide the ability to configure what tools I need and I don't necessarily expect it to push "use language servers". This can also boil down to hardware/software requirements if not all tools support the same architectures. This also removes features when there is not true feature parity.
I do think that deprecating and removing unmaintained projects for sure, but a large majority of these seem to just be pushing the narrative that everyone prefers language servers over smaller scoped static linters. This is not always the case especially when language servers are not always well written and you may not need/want everything they can do.
During the migration from clang-format to clangd I found a problem, the
--styleflag in clang-format doesn't work correctly in clangd (use--fallback-stylein clangd), I found this in the clangd issue and it's still open now, has anyone else encountered the same problem as I have?Is placing a clangd configuration file at
$XDG_CONFIG_HOME/clangd/config.yamlviable for you? (https://clangd.llvm.org/config#files)
I try to add my fallback-style config to config.yaml, but it seems doesn't work either. But I find that adding style config to .clang-format works fine to clangd, as the comment said: https://github.com/clangd/clangd/issues/362#issuecomment-1140325164]
Very bad decision to make I'm afraid. Why do you think users installed null-ls in the first place? We just want a universal method to configure some formatting or linting tools instead of adopting one lsp after another.
I do think that deprecating and removing unmaintained projects for sure, but a large majority of these seem to just be pushing the narrative that everyone prefers language servers over smaller scoped static linters. This is not always the case especially when language servers are not always well written and you may not need/want everything they can do.
That's why I encourage you to create plugins/just straight up copy it to your own config. If no one always keeps an eye on the integrations, new users could possibly get a bad experience from that. The whole repository is published into the public domain, so you are free to do it!
Very bad decision to make I'm afraid. Why do you think users installed null-ls in the first place? We just want a universal method to configure some formatting or linting tools instead of adopting one lsp after another.
While this is an easy way to configure integrations by parsing the output of other programs, it's very prone to breaking, due to various issues (e.g. #51, possibly caused by encoding mismatch? which isn't an issue in LSP). Furthermore, we need to handle debouncing, diffing and many more performance-wise optimizations ourselves and this is absolutely not optimal.
You can always easily plug something into none-ls and this won't change. I apologize for the inconvenience on the removed builtins, but I think a native LSP is the path forward for all editors. <3
I might consider adding those maintained ones to an -extras repository later, if enough people would like to actively keep an eye on this.
The problem here is that we don't have enough people to care for high-quality integrations (reality: I don't speak all the languages 😢), and I don't want many of them to be in a bad shape where no one could or is willing to fix it.
I'm really sorry if this breaks any of your config, but the fix should be trivial. If you are also willing to keep it working for everyone else, please say about it. It really makes a significant contribution to the project.
@mochaaP also you might want to add back clang_format since clangd does not actually replace it. It is good because it uses clang format for formatting C/C++ programs. But clang_format supports formatting Java files which clangd does not support for its language server
@mehalter
Sure will. I was today years old when I learned that 😅
See the docs of nvim-lspconfig, please: https://github.com/neovim/nvim-lspconfig/blob/master/doc/server_configurations.md
@mochaaP clangd is an LSP not a formatter, and I have already configured it like this:
lspconfig.clangd.setup {
on_attach = on_attach,
capabilities = capabilities,
}
but this won't format the code, is it even possible to use the LSP as a formatter? I don't think clangd-format should be deprecated.
@le4ker that is one of the capabilities that a language server can provide. It can provide formatting capabilities. clangd does provide this by bundling clang_format with itself
@le4ker that is one of the capabilities that a language server can provide. It can provide formatting capabilities.
clangddoes provide this by bundlingclang_formatwith itself
Exactly, that's why the clang-format is needed, right? 😅
No haha clangd bundles it with itself. It basically comes with a version of clang_format internally I'm pretty sure. That being said, clang_format formats more things than clangd has support for which is why it is still necessary
Is there any way to suppress the deprecation warning? I've been happily using clang_format, ruff, latexindent and shellcheck for the last year or so, and have absolutely no need to replace them at this time. The deprecation warning keeps popping up every single time I start nvim. Thanks!
No haha
clangdbundles it with itself. It basically comes with a version ofclang_formatinternally I'm pretty sure. That being said, clang_format formats more things thanclangdhas support for which is why it is still necessary
One issue for me is that when switching from clang_format to native LSP clangd, the auto-formatting on-save doesn't work anymore. I can still manually trigger it, but
on_attach = function(client, bufnr)
if client.supports_method "textDocument/formatting" then
vim.api.nvim_clear_autocmds {
group = augroup,
buffer = bufnr,
}
vim.api.nvim_create_autocmd("BufWritePre", {
group = augroup,
buffer = bufnr,
callback = function()
vim.lsp.buf.format { bufnr = bufnr }
end,
})
end
end,
doesn't work anymore. Again, manually invoking :lua vim.lsp.buf.format() works.
I'm using beautysh for formatting, but it's marked for removal.bashls and shfmt have been suggested as replacements, but neither of those seem to support zsh, which is what I use (it's the default on macOS). Are there any other formatters that supports zsh?
Since
clangduses https://github.com/llvm/llvm-project/tree/main/clang/lib/Format (clang-format's underlying logic), you can just configure it in lspconfig /clangd_extensions.nvimand it should work ootb.
Has anyone actually tested this? I don't see any formatting command in clangd command line that actually allows you to run formatting on a file. But maybe I am misunderstanding how the LSP/null-ls performs formatting.
Another good reason to keep clang-format separate either way is that some codebases use certain version of clang format as formatting changes between versions. Keeping it separate from clangd allows users to do so.
Thanks for taking the effort to dig in and maintain these tools! I saw there was some discussion above around the python tooling on this list. Here are a couple more points—some of which may apply to other items on this list:
TL;DR: My personal plea: do not remove flake8.
As others have said, just because ruff purports to replace and improve on many of these tools, it does not do so in an exact 1-to-1 manner. It might be feasible for a small project to migrate to ruff, but not so for a larger project with multiple developers who have customized each tool's configuration and written custom plugins and extensions for them. Indeed, one huge benefit of flake8 (which is still listed for removal as of this comment) is the ability and ease of writing custom plugins.
Many of these tools are used both in live-coding situations (show lints in the buffer, format on save, etc) as well as automated QA tooling (precommit, GH actions). In these situations, it's important to use the same exact tools, configurations, and versions in both situations. It's not uncommon for a developer to have little or no control over what's used for the automated QA tooling, so switching, e.g., from flake8 to ruff, is not a real option.
One of the promises of open source is choice. While I think it's fine and good to encourage users to switch to an LSP replacement when one exists, each person may have their own reason for sticking to none-ls. Maybe the LSP replacement has a subtle bug or oversight that only really affects that one person and shows no signs of getting fixed. Maybe the LSP replacement has way too many features and is complete overkill for the simple tool they were using before. Maybe they just don't want to put in the hour(s) of fiddling with their config. Maybe they have personal beef with the developer of the LSP replacement. The reason shouldn't really matter here.
My overall opinion here is that the only time a tool should be removed from none-ls is when its upstream is abandoned and it is no longer being used by a significant base (I do realize the latter can be hard to measure).
@Doekeb The problem with flake8 is that it's (1) [...]not aimed to support pyproject.toml1 (2) is lacking of active updates2 (3) it's not implementing any rules, but a wrapper for many tools. There are too many edge cases where we just can't cover, and I think moving it to -extras could be a reasonable move.
Footnotes
-
https://github.com/csachs/pyproject-flake8#rationale, https://github.com/PyCQA/flake8/issues/234 ↩
-
https://github.com/PyCQA/flake8/commits/main/
Pretty half of the commits in the last 2 years are not even touchingsrc/flake8. ↩
Can someone explain what is meant with "use taplo lsp"? I started getting those annoying deprecation messages and mason provides only taplo (which is an lsp to my knowledge), no such thing as a tool named "taplo lsp". If it really exist, you could at least provide a link to the utility you're suggesting migrating to.
Besides, before deprecating some tools I would advise to at least check that the alternatives exist, and offer at least the same level of functionality. There's a reason if some LSPs still are not widely adopted..
Another example is shellcheck: bashls does not provide a tiny fraction of the diagnostics/linting that shellcheck provides, so you are actually leaving people on their own to figure out how to lint their scripts.
Can someone explain what is meant with "use taplo lsp"?
I thought it was pretty self-explanatory. The first result on Google is nvim-lspconfig:
Another example is
shellcheck
See the Related Projects section. You could use https://github.com/gbprod/none-ls-shellcheck.nvim which is a drop-in replacement for the builtin.
bashlsdoes not provide a tiny fraction of the diagnostics/linting thatshellcheckprovides
bashls invokes shellcheck directly if installed. The diagnostics should be 1:1 matching.
@keith-rollin Unfortunately I didn't have any good luck finding an actually correct zsh formatter that's guaranteed to not break your script. I guess I will add beautysh to the -extras repo for now, until something new comes. /shrug
Yeah thanks so much!
flake8 is now available in https://github.com/nvimtools/none-ls-extras.nvim/blob/main/lua/none-ls/diagnostics/flake8.lua. :)
Can Eslint_d not be depreciated? Eslint-lsp is markedly slower than Eslint_d (errors/diagnostics are displayed instantly upon opening file rather than 5-6 seconds after)
@GR3YH4TT3R93: eslint_d is available in none-ls-extras.nvim.
I'm still extremely new to nvim, how would I tie that in with mason/ mason-null-ls or am I S.O.L. until they're integrated?
You can manually add eslint_d to mason.nvim's ensure_installed.
No, you can't. If called in mason.setup it does nothing. In mason-lspconfig, it throws an error that it's not a valid entry. How do I fix this?
This is an absolutely horrible discision.
This breaks countless ppl's configs and new devs are left with no way to fix their configs other than with extremely vague and unhelpful comments from the person actually making the changes.
This needs to be rolled back ASAP.