nvim-lint

# nvim-lint

An asynchronous linter plugin for Neovim (>= 0.9.5) complementary to the
built-in Language Server Protocol support.

## Motivation & Goals

With [ale][1] we already got an asynchronous linter, why write yet another one?

Because [ale][1] also includes its own language server client.

`nvim-lint` instead has a more narrow scope: It spawns linters, parses their
output, and reports the results via the `vim.diagnostic` module.

`nvim-lint` complements the built-in language server client for languages where
there are no language servers, or where standalone linters provide better
results.

## Installation

- Requires Neovim >= 0.9.5
- `nvim-lint` is a regular plugin and can be installed via the `:h packages`
  mechanism or via a plugin manager.

For example:

```bash
git clone \
    https://codeberg.org/mfussenegger/nvim-lint.git
    ~/.config/nvim/pack/plugins/start/nvim-lint
```

- If using [vim-plug][3]: `Plug 'mfussenegger/nvim-lint'`
- If using [packer.nvim][4]: `use 'mfussenegger/nvim-lint'`


## Usage

Configure the linters you want to run per file type. For example:

```lua
require('lint').linters_by_ft = {
  markdown = {'vale'},
}
```

To get the `filetype` of a buffer you can run `:= vim.bo.filetype`.
The `filetype` can also be a compound `filetype`. For example, if you have a buffer
with a `filetype` like `yaml.ghaction`, you can use either `ghaction`, `yaml` or
the full `yaml.ghaction` as key in the `linters_by_ft` table and the linter
will be picked up in that buffer. This is useful for linters like
[actionlint][actionlint] in combination with `vim.filetype` patterns like
`[".*/.github/workflows/.*%.yml"] = "yaml.ghaction",`


Then setup a `autocmd` to trigger linting. For example:

```vimL
au BufWritePost * lua require('lint').try_lint()
```

or with Lua auto commands:

```lua
vim.api.nvim_create_autocmd({ "BufWritePost" }, {
  callback = function()

    -- try_lint without arguments runs the linters defined in `linters_by_ft`
    -- for the current filetype
    require("lint").try_lint()

    -- You can call `try_lint` with a linter name or a list of names to always
    -- run specific linters, independent of the `linters_by_ft` configuration
    require("lint").try_lint("cspell")
  end,
})
```

Some linters require a file to be saved to disk, others support linting `stdin`
input. For such linters you could also define a more aggressive `autocmd`, for
example on the `InsertLeave` or `TextChanged` events.


If you want to customize how the diagnostics are displayed, read `:help
vim.diagnostic.config`.

## Security

Some linters prioritize using an executable relative to the current working
directory over the executable in `$PATH`. For example the `eslint` linter will
use `./node_modules/.bin/eslint` if it exists. The executable is executed with
your users permission. Because of that, you must _not_ call `try_lint()` in
untrusted repositories.

To improve security you could run linters using sandbox systems like
[bubblewrap]