none-ls.nvim: Community-Maintained null-ls for LSP Injection in Neovim

The Problem none-ls Solves in Neovim's LSP Ecosystem

Neovim has a built-in LSP client that works with language servers to provide features like diagnostics, code actions, and formatting. The limitation is that Neovim's LSP client only consumes output from actual language servers following the Language Server Protocol. Tools like formatters (Prettier, StyLua) and linters (ESLint, markdownlint) are not LSP servers; they are command-line programs with their own output formats.

The README describes this as a gap in the Neovim ecosystem compared to VS Code and coc.nvim, both of which provide mechanisms for non-LSP sources to hook into their LSP-like clients. none-ls (and its predecessor null-ls) bridge that gap by acting as a virtual language server inside Neovim. External tools are called through Lua, their output is translated into LSP-format responses, and Neovim's LSP client receives the result as if it came from a real language server. The README also notes a performance goal: removing the need for external language server processes by handling the translation inside Neovim itself.

Five LSP Feature Hooks and Their Scope

null-ls sources can hook into five LSP features: code actions, diagnostics at both the file and project level, formatting including range formatting, hover, and completion. The README notes that null-ls includes built-in sources for each of these features for common tools. The doc/BUILTINS.md file in the repository documents which built-in sources are available; the doc/BUILTIN_CONFIG.md file documents how to configure them.

Not all built-in sources have been fully retained in the community fork. The README notes that some sources require the companion plugin none-ls-extras.nvim. The setup example in the README shows this: the ESLint diagnostics source requires none-ls-extras.nvim and must be loaded via require, while the stylua formatter and spell completion are loaded directly from the null_ls.builtins namespace. This split means an operator must check which sources are bundled and which have been moved to none-ls-extras before configuring a workflow.

The README describes the plugin as being in beta status and developed against the latest stable version of Neovim. Support for Neovim builds from HEAD is on a best-effort basis.

Setting Up none-ls with a Package Manager

Installation follows the same steps as any Neovim plugin: add none-ls to the plugin manager configuration using nvimtools/none-ls.nvim as the repository identifier, and ensure plenary.nvim is also installed, as it is listed as a dependency in the README. After installation, null-ls must be configured with at least one source before any feature is active.

The README setup example registers a stylua formatter, a spell completion source, and ESLint diagnostics:

local null_ls = require("null-ls")

null_ls.setup({
    sources = {
        null_ls.builtins.formatting.stylua,
        null_ls.builtins.completion.spell,
        require("none-ls.diagnostics.eslint"), -- requires none-ls-extras.nvim
    },
})

Note that the require call at runtime uses null-ls (with a hyphen), matching the original API. The README explicitly states that only the repository name changed from null-ls.nvim to none-ls.nvim; the internal Lua module name and all API surfaces remain the same. This is why migrating from the original null-ls.nvim requires only changing the repository string in the package manager, not the Lua configuration.

Creating Custom Sources: Buffer Parsing and CLI Program Wrappers

Beyond built-in sources, none-ls exposes a Lua API for writing custom diagnostic, formatting, hover, and completion sources. The README documents two main patterns.

The first is a generator function that receives a params object with access to the current buffer's content and editor state. A custom source iterates over lines, detects patterns, and returns a list of diagnostic objects. The null_ls.methods namespace exposes method constants (DIAGNOSTICS, FORMATTING, HOVER, COMPLETION, CODE_ACTION) that a source declares to tell null-ls how to handle its output.

The second pattern uses null_ls.generator, a helper that spawns an external command, passes the buffer content to it, and captures its stdout or stderr output. The helper accepts arguments for the command name, the argument list, whether to send buffer content via stdin (to_stdin), which output stream to read (from_stderr), and the output format (raw, json, or line). The doc/HELPERS.md file in the repository documents the full set of options available when building a command-line wrapper. This pattern means integrating any CLI tool that reads stdin and writes line-based output requires writing a short Lua table rather than a full plugin, which is the core productivity claim of none-ls.

Migration from null-ls.nvim and Community Governance

null-ls.nvim, originally maintained by jose-elias-alvarez, was archived. none-ls.nvim is a direct continuation by community volunteers. The migration path documented in the README is minimal: replace jose-elias-alvarez/null-ls.nvim with nvimtools/none-ls.nvim in the package manager configuration. Because the API, module name, and built-in source names are preserved, no Lua configuration changes are required.

The governance model is open: any contributor can open a pull request to become a collaborator. Previous null-ls.nvim contributors can establish collaborator status by opening an issue or commenting on a relevant commit. Pull requests require a review from another collaborator before the author can merge, which provides a lightweight check without requiring a dedicated maintainer. The README notes this policy is subject to change as the collaborator count grows.

The repository has published no GitHub releases. The last push to the main branch was recorded on 2026-08-10. The repository is not archived. The Unlicense license places no restrictions on use, modification, or distribution.

Comparing with conform.nvim and nvim-lint

Since null-ls.nvim was archived, two focused plugins have become common alternatives in the Neovim community. conform.nvim handles code formatting and nvim-lint handles diagnostics. Each covers a narrower scope than none-ls and is maintained by a single focused author rather than a community fork. The trade-off is that a configuration using both requires coordinating two plugin APIs and two setup calls, while none-ls covers both features under one require call.

The practical difference in adoption comes down to which features a developer uses. A configuration that relies primarily on none-ls's formatting built-ins can often migrate to conform.nvim with comparable functionality. Configurations that use none-ls for custom diagnostic sources, code actions, hover, or completion will need to evaluate whether conform.nvim and nvim-lint together cover those use cases, as neither focuses on those feature areas.

none-ls has the advantage of a larger existing user base with worked examples and documentation inherited from null-ls, which can ease initial setup. New configurations not tied to existing null-ls examples may find the focused alternatives simpler to maintain.

Editorial conclusion

none-ls.nvim is the right choice for Neovim users who have an existing null-ls configuration and need a maintained drop-in replacement. New Neovim users building a configuration from scratch should evaluate whether the all-in-one approach fits their needs or whether splitting formatting to conform.nvim and diagnostics to nvim-lint gives clearer separation of concerns. Before migrating from null-ls, check the doc/BUILTINS.md file in the repository to confirm that the built-in sources your workflow depends on are present in none-ls.

Frequently asked questions

Official sources

1. Issues
2. License: Unlicense
3. nvimtools/none-ls.nvim on GitHub
4. README