Deprecating builtins with unmaintained upstream or native LSP replacement #81
Replies: 164 comments 121 replies
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
It's just for the upstream abandoned projects. pmd and checkstyle are all fine, since upstream actively maintains them :) |
Beta Was this translation helpful? Give feedback.
-
|
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. 😀 |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
|
Hi, I'm not sure if I missed something, but I lost my diagnostics and code actions. I was previously using xo for that. (Sometimes I feel like I'm the only nvim user using that.) So, I updated my config and replaced "xo" with "eslint" (because it looks like it's the way to go), and installed eslint-lsp with mason because I'm lazy. I don't use eslint at work, only xo, so I hope I didn't lose that. I just spent the day typing "yarn xo", which was boring. My config is here. I just replaced "xo" with "eslint" on lines 341 / 344 (yes, it's just one file). |
Beta Was this translation helpful? Give feedback.
-
|
You could drop a This should be picked up by ESLint. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah well, that's seems pretty overkill, I can't do that on every project we have. That's really disappointing. |
Beta Was this translation helpful? Give feedback.
-
|
I believe you can just create and maintain your own like this: https://github.com/gbprod/none-ls-php.nvim? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, i will try that, but i need time and i got zero knowledge. |
Beta Was this translation helpful? Give feedback.
-
|
related: #81 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
Titanic work you guys have done there. No one likes to move from something that was working just fine, but it's true everything that has been removed is deprecated. |
Beta Was this translation helpful? Give feedback.
-
|
Taplo is not deprecated, either... It's under active development, in fact. |
Beta Was this translation helpful? Give feedback.
-
If you would like to use xo in null-ls, use this in the require("none-ls.code_actions.eslint").with({
name = "xo",
filetypes = { "javascript", "javascriptreact", "typescript", "typescriptreact" },
command = "xo",
args = { "--reporter", "json", "--stdin", "--stdin-filename", "$FILENAME" },
})require("none-ls.diagnostics.eslint").with({
name = "xo",
filetypes = { "javascript", "javascriptreact", "typescript", "typescriptreact" },
command = "xo",
args = { "--reporter", "json", "--stdin", "--stdin-filename", "$FILENAME" },
})My opinions about the removal of `standardjs` and `xo`I don't like how they use ESLint under the hood, but don't have an easy way for users to expose the preset to vanilla ESLint, nor eject to vanilla ESLint. (standardjs does this better than xo, by having simple rules and directly using eslint-config-standard. xo uses multiple plugins, and eslint-config-xo isn't really synced to the main repo in time.) We (integration authors & maintainers) want to have a unified way for doing this, not having to repeat things multiple times and confuse users. |
Beta Was this translation helpful? Give feedback.
-
Like this ? |
Beta Was this translation helpful? Give feedback.
-
|
Ah yes. You also need to install none-ls-extras for this to work. |
Beta Was this translation helpful? Give feedback.
-
|
@mochaaP Great, thank you ! |
Beta Was this translation helpful? Give feedback.
-
|
How much time spent on trying to convince people to switch to different tools/supporting them with that switch will it take until any perceived benefits of the change are negated? What will it take for all builtins to be put back to where they are, or at least put on a level playing field? |
Beta Was this translation helpful? Give feedback.
-
|
there is a way that I can still keep using none-ls with eslit_d? really bad that you guys dropped something that work just fine |
Beta Was this translation helpful? Give feedback.
-
|
:upside_down: |
Beta Was this translation helpful? Give feedback.
-
|
where do I put this code? |
Beta Was this translation helpful? Give feedback.
-
|
@hxsggsz You can see my nvim configuration. https://github.com/citosid/vim/blob/3dbe530186451342973be0fddb6e2e10099f1240/lua/plugins/none-ls.lua In line 30 is where the new plugin is added and in line 55 onward is where the new alternatives are being used. I'm using |
Beta Was this translation helpful? Give feedback.
-
|
The value that I found in this plugin has always been that it was a one stop shop for setting up linting/formatting/code actions. That value has been completely eroded with this change and I'll be migrating off it as soon as possible. |
Beta Was this translation helpful? Give feedback.
-
|
For anyone trying to reconfigure |
Beta Was this translation helpful? Give feedback.
-
|
@mochaaP Did something change recently? I've lost access to locally installed |
Beta Was this translation helpful? Give feedback.
-
|
I guess you need to point it to |
Beta Was this translation helpful? Give feedback.
-
|
I've never had this issue before and a computer restart fixed it. Very strange, probably a fault with |
Beta Was this translation helpful? Give feedback.
-
|
No worries, tag me anytime if you need help 😉 |
Beta Was this translation helpful? Give feedback.
-
|
my squad, and all other squads, have various configs setup for flake8, and all other standard formatters (black etc), right down to pre-commit hooks and various checks in CI. I use neovim and to see this being deprecated / removed is just abit irratating. Moving to ruff shouldn't be something that is forced upon people. |
Beta Was this translation helpful? Give feedback.
-
|
black et al. now lives in none-ls-extras. |
Beta Was this translation helpful? Give feedback.
-
|
I really appreciate this decision moving on with none-ls! Null-ls's downfall was the fact that it attempted to support EVERYTHING and the more it added the harder it became to maintain. I recommend for those, that still want to use removed sources, to provide an injection factory by use at your own risk but please don't open any issues on unmaintained sources. |
Beta Was this translation helpful? Give feedback.
-
|
Null-LS also tried to maintain null-ls for earlier neovim versions. What is you stance on that? I personally don't think its necessary or even good for the health of none-ls to support old versions such as neovim 5. |
Beta Was this translation helpful? Give feedback.
-
|
could be the same as mini.nvim. i haven't thought much on that (yet)! |
Beta Was this translation helpful? Give feedback.
-
|
xmllint is a good linter. I do not want to install lemminx due to java dependency. |
Beta Was this translation helpful? Give feedback.
-
Hi, could you submit a PR for xmllint to none-ls-extras? Thanks :) |
Beta Was this translation helpful? Give feedback.
-
|
Could you just revert your change on this linter? |
Beta Was this translation helpful? Give feedback.
-
|
Done in e22c380 |
Beta Was this translation helpful? Give feedback.
-
The formatting/lua_format.lua uses Koihik/LuaFormatter which is different from stylua. |
Beta Was this translation helpful? Give feedback.
-
|
mason-null-ls fork with support for none-ls external sources: https://github.com/Zeioth/none-ls-autoload.nvim |
Beta Was this translation helpful? Give feedback.
-
|
My eslint diagnostics just completely stopped today, and I think that this is likely the reason why. I tried to adapt my configuration to the changes by doing the following: local null_ls_status_ok, null_ls = pcall(require, "null-ls")
if not null_ls_status_ok then
return
end
-- https://github.com/jose-elias-alvarez/null-ls.nvim/tree/main/lua/null-ls/builtins/formatting
local formatting = null_ls.builtins.formatting
-- https://github.com/jose-elias-alvarez/null-ls.nvim/tree/main/lua/null-ls/builtins/diagnostics
local diagnostics = null_ls.builtins.diagnostics
null_ls.setup({
debug = false,
sources = {
formatting.prettier.with({
extra_args = function(params)
if params.filetype == "ruby" then
return { "--config", "--plugin=@prettier/plugin-ruby" }
end
return {
"--config",
"--arrow-parens",
"avoid",
}
end,
extra_filetypes = { "ruby" },
}),
formatting.black.with({ extra_args = { "--fast" } }),
formatting.stylua,
formatting.sql_formatter,
formatting.golines,
formatting.gofmt,
formatting.shfmt,
diagnostics.rubocop,
require("none-ls.diagnostics.eslint"),
},
diagnostics_format = "[#{c}] #{m} (#{s})",
})I also got the following set up: use({ "nvimtools/none-ls.nvim", requires = {
"nvimtools/none-ls-extras.nvim",
} })
use({
"pmizio/typescript-tools.nvim",
requires = { "nvim-lua/plenary.nvim", "neovim/nvim-lspconfig" },
config = function()
require("typescript-tools").setup({})
end,
})Are there any other changes that need to occur here in order for my ESLint warnings to show up in my editor again? |
Beta Was this translation helpful? Give feedback.
and others
-
Related projects:
I'm thinking of cleaning up some builtins with the following criteria:
Planned to remove (will keep updating):
edit history → #58 (comment)
[Expand] If you get confused on some entries:
[Expand] If you just wanted a way to suppress the warning:
Beta Was this translation helpful? Give feedback.
All reactions