snacks.nvim: a bundle of Neovim quality-of-life modules you enable one at a time

What snacks.nvim actually is: many small plugins, one repository

The README opens by calling snacks.nvim "a collection of small QoL plugins for Neovim", and the feature table backs that up with more than thirty entries. They are not variations on one idea. bigfile handles large files, bufdelete removes buffers without disturbing window layout, gitbrowse opens the current file or commit in a browser, image renders images through the Kitty Graphics Protocol on kitty, wezterm and ghostty, and zen is a distraction-free mode. A handful are libraries rather than features: animate supplies over 45 easing functions, and util is described as utility functions for Snacks.

The audience is the Neovim user who already assembles a config from separate plugins and is tired of the resulting sprawl. Instead of adding a picker plugin, an indent plugin, a notifier plugin and a terminal plugin as four independent dependencies, you add one repository and select modules inside a single opts table. The trade is that you now depend on one author's release cadence for all of them at once, and the README's feature table is the only place that lists the whole set. The repository layout confirms the split: a lua/ tree for the modules, a docs/ directory with one markdown file per module, and a doc/ directory for Vim help.

The opt-in rule: nothing runs until you name it

The installation section carries a caution that is easy to skim past: "You need to explicitly pass options for a plugin or set enabled = true to enable it." An empty opts table therefore gives you nothing. This is the opposite of the usual Neovim plugin pattern, where installing a plugin and calling setup() turns on its default behaviour. Here the setup call creates autocmds and, per the README, does not load any plugins.

The feature table marks which modules need configuration with a double exclamation icon. bigfile, dashboard, explorer, image, input, notifier, picker, quickfile, scope, scroll, statuscolumn and words carry that mark. The rest, including git, gitbrowse, keymap, layout, lazygit, profiler, rename, scratch, terminal, toggle and zen, do not. That distinction is the practical map of the project: the unmarked modules are largely libraries or command-driven utilities you invoke when you need them, while the marked ones change behaviour in your editing session and expect a decision from you.

One more note from the README matters for ordering. A couple of plugins require snacks.nvim to be set up early, which is why the example config sets priority = 1000 and lazy = false. If you load snacks lazily, those modules may miss the events they hook.

Installing snacks.nvim with lazy.nvim and enabling a first module

The README gives a lazy.nvim spec directly. It pins priority = 1000 and lazy = false so the setup runs before other plugins, and it enables a set of modules by giving each one an enabled = true. Copy it and keep only the modules you want; the README's own example enables bigfile, dashboard, explorer, indent, input, picker, notifier, quickfile, scope, scroll, statuscolumn and words.

{
  "folke/snacks.nvim",
  priority = 1000,
  lazy = false,
  ---@type snacks.Config
  opts = {
    bigfile = { enabled = true },
    dashboard = { enabled = true },
    explorer = { enabled = true },
    indent = { enabled = true },
    input = { enabled = true },
    picker = { enabled = true },
    notifier = { enabled = true },
    quickfile = { enabled = true },
    scope = { enabled = true },
    scroll = { enabled = true },
    statuscolumn = { enabled = true },
    words = { enabled = true },
  },
}

With that in place, restart Neovim and run the health check the README recommends. It reports whether the modules you enabled are set up correctly:

:checkhealth snacks

The README states the requirements plainly: Neovim 0.9.4 or newer. Icons need one of mini.icons or nvim-web-devicons, and optionally a Nerd Font. Both icon plugins are marked optional, so a config without them will still load, with plainer glyphs. There is no homepage listed for the project, so the repository on GitHub is the place to read module documentation.

Where snacks.nvim gets in your way

The opt-in rule cuts both ways. Because setup loads nothing, a module you forgot to enable fails silently: no error, no warning, just a feature that never appears. If you expect a picker keymap to exist after installing snacks.nvim and you did not set picker = { enabled = true }, the keymap is not there. That is a configuration mistake the plugin does not catch for you, and the README's caution is the only warning you get.

The top-level README also does not document module configuration. It says to refer to the readme of each plugin for their specific configuration, and the default options block in the README is a type annotation listing config classes such as snacks.bigfile.Config and snacks.picker.Config rather than the fields inside them. So the real documentation lives in docs/<module>.md, one file per module, and there is no single page that describes the whole configuration surface. Evaluating the project means reading several files.

The bundle shape is a second constraint. If you want the picker but not the dashboard, you still install the repository that contains both, and you track one version number across all of them. A bug in a module you do not use can still appear in the changelog you are reading.

Finally, the image module depends on the terminal, not on Neovim alone. The README names kitty, wezterm and ghostty as the terminals that support the Kitty Graphics Protocol it uses. In any other terminal, that module has nothing to draw with.

snacks.nvim picker compared with Telescope and fzf-lua

The picker is the module most likely to be evaluated against an existing setup, and the search terms around this project confirm that people compare it with Telescope and fzf-lua. The difference in approach is architectural rather than cosmetic.

Telescope is a picker framework: it ships a set of built-in pickers and a documented API for writing your own, and extensions are separate repositories that plug into it. fzf-lua takes the opposite route and drives the external fzf binary, so its behaviour and performance characteristics follow that process. snacks.nvim's picker sits inside a larger collection. The same repository that provides it also provides the explorer, which the README describes as "a file explorer (picker in disguise)", meaning the explorer is not a separate tree implementation but the picker configured for files.

That is the real trade. Choosing snacks.nvim's picker means the explorer, and any other module that reuses the picker, comes from the same code path and the same release. Choosing Telescope or fzf-lua means you keep a picker that is developed on its own schedule and, in fzf-lua's case, delegates matching to a tool you may already have installed for the shell. Neither approach is strictly better; they differ in how much of your config moves at once when the plugin updates.

Maintenance status and the cost of upgrading

The repository is not archived. The last push to main was on 2026-05-25, which is the fact to weigh rather than any adjective. The most recent release listed is v2.31.0 from 2026-03-20, preceded by v2.30.0 on 2025-11-06 and v2.29.0 on 2025-11-04. Releases are versioned, so upgrades are checkpoints rather than a moving target, and a CHANGELOG.md sits at the top level of the repository for reading what changed between them.

Upgrade cost depends on how many modules you enabled. A config that turns on twelve modules has twelve surfaces to re-check after a version bump, and the per-module docs are where the details live. The health check is the cheap first pass after any upgrade, since it reports setup problems rather than waiting for a feature to misbehave.

The licence is Apache-2.0, stated in the repository and in the LICENSE file at the top level. That is a permissive licence with an explicit patent grant, which matters if you are vendoring the code or shipping a Neovim distribution rather than just installing it as a plugin. If you redistribute a modified copy, the licence's notice and attribution conditions apply; read LICENSE rather than a summary of it, and treat that as a question for whoever handles licensing on your side.

Editorial conclusion

Adopt snacks.nvim if you run Neovim 0.9.4 or newer and want picker, explorer, indent guides, terminal and notifier behaviour from one repository with one configuration table, accepting that each module must be enabled explicitly and that a module you leave out is simply absent. Do not adopt it if you want a single-purpose plugin with one documented behaviour to audit, or if you are on an older Neovim, since the README sets the floor at 0.9.4. Before wiring it into a config you depend on, run :checkhealth snacks after setup, and read the individual docs/<module>.md file for every module you turn on, because the top-level README defers module configuration to those files rather than describing it itself.

Frequently asked questions

Official sources

1. folke/snacks.nvim on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases