nvim-lite: a single-file Neovim configuration with no plugin manager

One init.lua and the end of the plugin manager

nvim-lite describes itself as a Neovim configuration in a single file, and the first line of its README says there is no plugin manager and no bloat. That is the whole design in one sentence.

The mechanism is Neovim's native vim.pack. The features list states it plainly: single init.lua, no plugin manager, uses Neovim's native vim.pack. The repository layout backs that up. Apart from the README, there is only .luacheckrc, .luarc.json, the init.lua itself and nvim-pack-lock.json.

The lock file matters. Where a plugin manager configuration usually carries a plugin list and a version pin, nvim-pack-lock.json is the resolved set of plugins the configuration actually fetched, and it is checked in. So the configuration is reproducible in the sense that the dependency set is recorded, but it is a single committed artifact that you inspect rather than a manifest you extend.

The .luacheckrc and .luarc.json files point the other way, and it is a useful detail. A Lua configuration that ships linting rules for itself means the author expects you to edit the file, and gives you the tooling to check your edits without leaving the editor. The cost is that every personalisation happens inside a file somebody else wrote, in a single file, with no per-user override layer described anywhere in the README.

Neovim 0.12 is a floor, and the rest is a list of external tools

The requirements section is short and specific. Neovim 0.12 or later is the first item, followed by a Nerd Font, with FiraCode Nerd Font recommended, and then a line of command line tools: git, ripgrep, fzf and fd. Go is listed separately, with a note that it is for efm-langserver.

The version number is the significant part. Neovim 0.12 is required rather than merely recommended, which in practice means this configuration is tied to a recent release and to the native vim.pack interface inside it. A developer on an older Neovim will find the whole file unusable rather than partially usable.

The dependency list also explains what each piece of the configuration does for a living. ripgrep and fzf are what the fuzzy finding commands and live grep are built on, fd is what fast file finding uses, and the Nerd Font is needed because the statusline and icons rely on the patched glyphs. The Go toolchain exists because efm-langserver needs it for linting and formatting.

One native dependency deserves a note: LuaSnip, used for snippet expansion, needs lua-jsregexp, a C library, and the README installs it as a system package. That is the only place in the setup where a compiled dependency has to be present before Neovim starts, and it is the step most likely to be missed when a snippet silently does not expand.

The install line writes over your init.lua

Installation is one command that creates the configuration directory and downloads the file into it.

mkdir -p ~/.config/nvim && curl -fsSL https://raw.githubusercontent.com/radleylewis/nvim-lite/main/init.lua -o ~/.config/nvim/init.lua

The README follows it with a note that if you already have a Neovim config, you should back it up first. That is not a formality. The command targets ~/.config/nvim/init.lua directly, so an existing configuration is replaced rather than merged, and there is no plugin-manager style import of your own file.

There is a detail to check before running it. The download URL points at the main branch, while the repository's default branch is recorded as master. Those are not the same ref, so the command either fetches a branch that exists and differs from the default, or it fails outright with the -f flag and the file is never written. Either way, the thing to verify is that the URL in the README resolves to the content you expect before it overwrites your config.

The system packages come next, and the README lists them as separate installs because they have different purposes:

sudo pacman -S neovim tree-sitter-cli

sudo pacman -S go

sudo pacman -S lua-jsregexp

sudo pacman -S git ripgrep fzf fd

The pacman commands assume an Arch-family distribution. On another distribution the package names differ and you will need the equivalents for your system.

Language servers arrive through Mason, except the Rust one

Language servers are handled by Mason, and the README is explicit about the workflow: on first launch, open Neovim and run :Mason to install the servers you need.

That single sentence encodes a deliberate choice. The configuration does not ship a server list, and it does not install anything for you on first launch. You pick what you need from the Mason interface. For a setup that is meant to be readable, that is consistent: the file describes how to talk to a language server, and the set of servers is your decision.

The Rust path is the exception, and the README flags it. rust_analyzer is managed automatically by rustaceanvim via rustup, and the instruction is to install it with rustup component add rust-analyzer rather than through Mason. If you install rust_analyzer through Mason as well, you end up with two copies and a version mismatch between what rustaceanvim expects and what Mason placed.

For the rest of the toolchain, the configuration wires together named components: Treesitter for syntax highlighting and folding, nvim-lspconfig with blink.cmp for completion, efm-langserver for linting and formatting, rustaceanvim for Rust, fzf-lua for fuzzy finding, nvim-tree for the file tree, and mini.diff with mini.git for git.

One optional feature has a filesystem requirement rather than a package requirement: the Obsidian note-taking support is optional and requires a ~/Documents/Notes/ directory to exist. The README does not say what happens if it does not, so treat that as something to check on your machine rather than assume it is inert.

The keymap set is small, and hunk navigation is the interesting part

The keymaps table is where a configuration like this either earns its place or does not, and this one is deliberately short. Tree, find files, live grep, buffers and a floating terminal all sit under the leader, with the terminal on <leader>t and closed with <C-q>. Language work is on <leader>gd for go to definition, <leader>ca for code action, <leader>rn for rename symbol and K for hover documentation.

The git entries are the ones that stand out. ]h and [h move to the next and previous git hunk, <leader>hs stages a hunk, and <leader>hb opens git blame. That is a hunk oriented workflow rather than a file oriented one: you move through changes at the granularity the editor is actually showing you, and you stage one change without leaving the buffer.

mini.diff and mini.git are the components behind that, and they are the reason the hunk keys exist at all. The mode indicator in the statusline, which also shows the branch, filetype and file size, is the surface that tells you which of those modes you are in.

What is absent is as telling as what is present. There is no completion-menu tuning keymap, no window management layer and no debugger integration listed. A configuration that omits those is not going to convert someone who arrived from a heavier setup, which is exactly the trade the README is making.

A licence the repository does not state and releases that do not exist

Two governance facts are worth having in front of you before you adopt this configuration.

The first is the licence. It is listed as unknown, and the top-level entries are .luacheckrc, .luarc.json, README.md, init.lua and nvim-pack-lock.json. There is no LICENSE file. That is not a prohibition on using it, and it is not a legal opinion, but it does mean there is no stated grant of use, modification or redistribution that you can point to. For a personal configuration that is a footnote. For a configuration copied into a company dotfiles repository that other employees rely on, it is a question to ask the author.

The second is release discipline. The repository has no GitHub releases at all, so there is no tagged version to pin and no changelog entry to diff against. The upgrade story is: take the current init.lua from the default branch, or take the committed nvim-pack-lock.json and understand that the plugin set behind it moves when the plugins move.

On activity, the last push was on 2026-08-09. There is no commit cadence claim to make from that date alone, but it does show the tree is not abandoned. What it does not show is how quickly breakage arrives when Neovim itself moves, and for a configuration pinned to 0.12 or later that is the risk that matters.

Where a full distribution configuration differs

The alternative is a community distribution configuration built on a plugin manager, where a plugin manager resolves and pins dozens of plugins, a large community maintains the keymaps, and the configuration is split across many files with an override layer for personal preferences.

The difference in approach is about where the decisions live. nvim-lite makes them once, in one file, and expects you to read it. A distribution configuration delegates them to a community and to the plugin manager's own defaults, and gives you a configuration that changes under you as the plugins are updated.

There is a real argument for each. A curated single file is legible, has a bounded dependency set, and its behaviour can be traced to lines you can read. A distribution configuration is broader, updated by many people, and easier to adopt when you do not want to make choices at all.

The failure modes are mirror images. nvim-lite breaks when Neovim moves and when you need a feature the author decided against. A distribution configuration breaks when a plugin changes behaviour or when a keymap you relied on moves, and it breaks in a way you did not author and cannot read in one place.

If you have spent time in a heavier setup and want to shrink, nvim-lite is a coherent destination. If you want features the author left out, it is not, and editing the file is the intended path.

Editorial conclusion

nvim-lite fits a developer who wants a readable, curated Neovim setup they can actually hold in their head, on a machine where they already have git, ripgrep, fzf, fd, Go and the Treesitter CLI installed, and who is willing to treat a one-line curl as the whole installation. It does not fit a team that needs a documented licence, a pinned plugin set with a support policy, or a configuration that lives outside its own file. Verify first that your Neovim is 0.12 or later, that the branch in the install URL resolves, and that the plugin set in nvim-pack-lock.json matches what your project expects.

Frequently asked questions

Official sources

1. Issues
2. radleylewis/nvim-lite on GitHub
3. README