Linter/Fixer

[kristijanhusak]

What?
Basically https://github.com/dense-analysis/ale, but only linter and fixer. Other things are already implemented via lsp.

Why?
Linting is a thing that runs almost constantly, especially when real time execution is enabled. I believe having it in lua would improve the performance.

Potential existing implementations:

• https://github.com/dense-analysis/ale
• https://github.com/neomake/neomake
• https://github.com/vim-syntastic/syntastic

Potential pitfalls:
Migrating all linter/fixer implementations that exist in ale, from vimscript to lua.
Guess it can be done slowly over time.

I'm not a lua developer, but I can definitely help on this.

[wbthomason]

Just to clarify, this differs from the LSP-provided diagnostics in that it focuses on running standalone linters?

[kristijanhusak]

@wbthomason yeah, standalone linters and fixers. For example, most JS projects use eslint for linting, and prettier for fixing.

[carlitux]

@kristijanhusak I just started using https://github.com/neovim/nvim-lspconfig#diagnosticls right now dealing with some issues configuring but looks like it is a replacement of ale. But I still need some time to confirm that is an alternative.

[kristijanhusak]

@carlitux I wasn't aware of that. I'll give it a try, thanks!

[carlitux]

@kristijanhusak were you able to setup? I had many issues diagnosticls

[kristijanhusak]

@carlitux i haven't tried yet. Will get back to you when i try it.

[weilbith]

How you describe "fixers" sounds actually more like a code formatter. At least that's what your example Prettier is doing. It does not fix your code. It just makes it standardized formatted. But it would deny to format if there are syntax errors for example.
A tool that support this would be neoformat

[wbthomason]

Also https://github.com/mhartington/formatter.nvim

[carlitux]

@wbthomason plans to support linters?

[wbthomason]

@carlitux Sorry, support linters in what? formatter.nvim is not my project; this repo is just a place to collect ideas for people to adopt and implement.

[carlitux]

@wbthomason sorry, I didn't read well. Thanks!

[kristijanhusak]

@carlitux I managed to set up linting with eslint, and prettier, with this config:

nvim_lsp.diagnosticls.setup{
  filetypes={'javascript'},
  init_options = {
    linters = {
      eslint = {
        command = './node_modules/.bin/eslint',
        rootPatterns = {'.git'},
        debounce = 100,
        args = {
          '--stdin',
          '--stdin-filename',
          '%filepath',
          '--format',
          'json'
        },
        sourceName = 'eslint',
        parseJson = {
          errorsRoot = '[0].messages',
          line = 'line',
          column = 'column',
          endLine = 'endLine',
          endColumn = 'endColumn',
          message = '${message} [${ruleId}]',
          security = 'severity'
        },
        securities = {
          [2] = 'error',
          [1] = 'warning',
        },
      },
    },
    filetypes = {
      javascript = 'eslint'
    },
    formatters = {
      prettier = {
        command = "./node_modules/.bin/prettier",
        args = {"--stdin-filepath" ,"%filepath", '--single-quote', '--print-width 120'}
      }
    },
    formatFiletypes = {
      javascript = "prettier"
    },
  }
}

I wasn't able to set up eslint fix or prettier-eslint, it failed to spawn those, even though I have them installed. Linting looked fine.
It doesn't work for me because I thought it supports textDocument/range_formatting, which is the only thing I'm currently missing from Ale.

[carlitux]

@kristijanhusak issues with 'textDocument/definition' or 'textDocument/documentSymbol'? for me breaks others

[kristijanhusak]

@carlitux I didn't try to run any other LSP server besides it. Most likely there would be some issues in that case.
I don't think it can work if you have more than 1 LSP per filetype.

[vinnyA3]

Great stuff .. the config you posted worked perfectly @kristijanhusak

It would be nice to see the bugs worked out with multiple LSPs & single files. I was running a JS lang server & diagnosticls; unfortunately, ran into similar issues as @carlitux .

Here's one of multiple LSP bugs that's currently being addressed: neovim/neovim#12764

[lucastrvsn]

@carlitux I managed to set up linting with eslint, and prettier, with this config:

nvim_lsp.diagnosticls.setup{
  filetypes={'javascript'},
  init_options = {
    linters = {
      eslint = {
        command = './node_modules/.bin/eslint',
        rootPatterns = {'.git'},
        debounce = 100,
        args = {
          '--stdin',
          '--stdin-filename',
          '%filepath',
          '--format',
          'json'
        },
        sourceName = 'eslint',
        parseJson = {
          errorsRoot = '[0].messages',
          line = 'line',
          column = 'column',
          endLine = 'endLine',
          endColumn = 'endColumn',
          message = '${message} [${ruleId}]',
          security = 'severity'
        },
        securities = {
          [2] = 'error',
          [1] = 'warning',
        },
      },
    },
    filetypes = {
      javascript = 'eslint'
    },
    formatters = {
      prettier = {
        command = "./node_modules/.bin/prettier",
        args = {"--stdin-filepath" ,"%filepath", '--single-quote', '--print-width 120'}
      }
    },
    formatFiletypes = {
      javascript = "prettier"
    },
  }
}

I wasn't able to set up eslint fix or prettier-eslint, it failed to spawn those, even though I have them installed. Linting looked fine.
It doesn't work for me because I thought it supports textDocument/range_formatting, which is the only thing I'm currently missing from Ale.

Awesome! I was trying to do this today and this worked really well. Maybe we need some docs for right configuration?

[carlitux]

Great stuff .. the config you posted worked perfectly @kristijanhusak

It would be nice to see the bugs worked out with multiple LSPs & single files. I was running a JS lang server & diagnosticls; unfortunately, ran into similar issues as @carlitux .

Here's one of multiple LSP bugs that's currently being addressed: neovim/neovim#12764

looks like this is fixed and working really well, just trying to find the best way to format before save right now with this config

  if client.resolved_capabilities.document_formatting then
    vim.cmd("autocmd BufWritePre <buffer> lua vim.lsp.buf.formatting_sync{}")
  end

[matu3ba]

Newer programming languages provide one tool for the linting. Older programming languages have many.

Is the goal to simplify or give any sort of reference on this?

[kristijanhusak]

@matu3ba literally a tool same as Ale mentioned in the first comment, but only the linter and fixer part. Ale has some other things that are not necessary since they are already implemented (LSP for example).

[icew4ll]

Does the linter/fixer need to be in lua when there is already an option to use the efm-languageserver (written in go) with lspconfig? The suggestion to use efm-language server for linting and formatting in neovim was made here efm-languageserver. I have been using this solution for a variety of languages and it works very well my implementation can be referenced here dots.

[fsouza]

nvim-lint is promising: https://github.com/mfussenegger/nvim-lint/

[matu3ba]

I would suggest to keep linter and fixer separate programs as the fixer rewrites the file with the possibilities to mess up your files.
(So I prefer to invoke simple binaries that may optionally read a project-local config and always work/never fail as to limit any possibilities of errors.)

The linter should only do static code analysis (on source- or intermediate representation) of the code.

[fsouza]

@matu3ba agreed, right now I'm looking at nvim-lint and formatter.nvim as two strong candidates, but I still use efm personally.

[FardeenCodes]

Can anyone help me setting up nvim-lint for pylint(python)

[wbthomason]

Can anyone help me setting up nvim-lint for pylint(python)

I would suggest that you ask on the nvim-lint repo - this repo is for gathering wishes and candidates for their fulfillment.

[sarmong]

You can try using null-ls. This plugin allows pretty much anything to be hooked up to the existing lsp protocol.

It includes plenty of builtins for different linters an formatters

[luisiacc]

I guess this is already done right? via what @sarmong mentioned, https://github.com/jose-elias-alvarez/null-ls.nvim

[mjlbach]

I would recommend nvim-lint, between the two of these what else are people missing?

[kristijanhusak]

I'm currently using https://github.com/creativenull/diagnosticls-configs-nvim, which provides predefined configs for diagnosticls.

[gegoune]

@mjlbach Would you mind elaborating a bit on why you recommend using nvim-lint over null-ls, please? Genuinely curious.

[mjlbach]

• I don't think a linter, formatter, and (now) completion source should be part of the same plugin. It makes sense in the case of a language server, because a language server inherently shares components (parsing the files and updating with changes) but linters/formatters are usually entirely separate and run out of process. nvim-lint has a clear focus/lack of feature creep.
• The nvim-lint core is extremely readable/small/clean (~350 LoC), it's around 10x smaller than null-ls (~3K LoC)
• By virtue of that scope, nvim-lint doesn't touch the LSP code. It doesn't inject itself as a language server, it doesn't hijack buf_request, the rpc loop, etc. This has caused me (personally) headaches in the past from user bug reports.

IMO People just want OOTB configurations for linters/formatters,which is what null-ls happens to provide in a single plugin. I don't think these should be in the same plugin, and I certainly don't think it should be forced into the language server protocol.

nvim-lint also provides linters OOTB but not formatters. I think nvim-lint + a dedicated formatter plugin like formatter.nvim is the way to go.

[gegoune]

Thanks you very much for taking time to describe it in such detail. Really appreciated.

[Mte90]

I see that the difference between null-ls and nvim-lint is that the first one is for linter and fixer and the second only for linters.

so there is a plugin just for fixers/formatters? something where you define a filetype and what to execute should be enough.

[bb010g]

I really want a Neovim Lua ecosystem equivalent to ALE's amazing auto-configuration (not auto-installation) of linters, fixers, and language servers. It's amazingly nice to be able to recommend to a new person that they should use a combo like packer.nvim + plenary.nvim + vim-polyglot + nvim-treesitter (ensure_installed = "maintained") + ALE and have an immediately rich, quick-starting editor for most situations without having to keep fiddling with config; currently there's no combo to replace ALE there. (Bonus points if it can auto-configure for DAP as well as LSP.)

Both null-ls.nvim and nvim-lint follow the current pattern and don't provide auto-configuration for linters.

[mjlbach]

I'm not sure I understand. Do you want users to have to opt-out of linters?

require('lint').linters_by_ft = {  markdown = {'vale',} }
vim.cmd [[ au BufWritePost * lua require('lint').try_lint() ]]

Does not seem like much configuration at all.

[bb010g]

@mjlbach That is how ALE generally works, yes. (ALE will disable tools by default if they're found to be poor fits for auto-detection.)

" Only run linters named in ale_linters settings.
let g:ale_linters_explicit = 1

I'd be fine with having auto-detection be opt-in; the complete lack of it is what I'm missing. I should note that :ALEInfo works with the auto-detection system to tell you what's enabled or disabled for your buffer and what it's tried so far and what's failed (generally it stops trying a tool after failure), as well as a log of tool invocations. That does a lot to keep it from surprising you. This is also where you'll see that certain tools were disabled by default, so you can figure out for a tool you're missing whether you can just turn it on or if you should submit a patch upstream adding a configuration for that tool.

Auto-detection is really nice when tools are only installed project-locally (e.g. via nix-shell), as two projects can run different sets of tools for the same language, and auto-detection keeps warnings from popping up repeatedly about missing executables as you switch between directories. Additionally, nix-shell means that I don't look at what linters or language servers a project has set up in its shell.nix when starting most of the time; they'll just be present once I enter the shell, ALE will find them, and things will just work. This is a sore spot with current null-ls.nvim; I have a helper function to create the explicit executable condition for each source I use so I won't get a varying amount of missing tool warnings popping up when I open a buffer.

It's also just annoying when I know these plugins know which tools work for which languages and can easily & quickly figure out what I have installed. It's boilerplate that I shouldn't have to write. Also, when you use a lot of languages, the boilerplate adds up.

I think being able to enable or disable auto-detection globally or buffer-locally and by language/filetype and tool would work (Again, you can mostly refer to what ALE currently has in terms of options.)

I do think tool auto-detection could be split out into a separate plugin that can be shared between other plugins that need to deal with detecting the tools and their appropriate configuration & directories; the ALE situation of everything being in one plugin doesn't need to be emulated.

[mfussenegger]

I do think tool auto-detection could be split out into a separate plugin that can be shared between other plugins that need to deal with detecting the tools and their appropriate configuration & directories; the ALE situation of everything being in one plugin doesn't need to be emulated.

Agreed, someone could create a nvim-lint-autoconf on top of nvim-lint for that.
I have no plans to extend nvim-lint itself with something like that for now

[ajitid]

nvim-lint also provides linters OOTB but not formatters. I think nvim-lint + a dedicated formatter plugin like formatter.nvim is the way to go.

Funnily enough, the maintainer of formatter.nvim once recommended to use efm. See this and this.

And somebody is collating quick configs for it: https://github.com/creativenull/efmls-configs-nvim