Why Neovim needs a Plugin Manager.

Life without a manager

Modern Neovim is mostly plugins. LSP, completion, fuzzy finding, file trees, themes — none of that ships with the editor. So what does installing a plugin look like with no tooling at all?

You hand-roll it. Neovim auto-loads anything inside pack/*/start/, so the bare-metal recipe is:

mkdir -p ~/.local/share/nvim/site/pack/dev/start
cd ~/.local/share/nvim/site/pack/dev/start
git clone https://github.com/folke/tokyonight.nvim
git clone https://github.com/morhetz/gruvbox
# ...repeat for every plugin you want.

Now multiply that by twenty plugins, two of which depend on a third, one of which has a known-bad commit you need to avoid, three of which slow your startup if loaded eagerly, and zero of which auto-update. You manage runtimepath by hand. You order load. You diff git pull outputs. You version-pin nothing.

This works. People did it for years. It's just a job that nobody should be doing by hand.

What a manager buys you

A plugin manager replaces every line of that recipe with a single declarative file. You describe what you want; the manager handles the rest.

The five jobs a real manager does for you:

• Declarative spec — plugins live in code, not in folder placement. Move machines, copy the file, you're done.
• Dependency resolution — telescope.nvim needs plenary.nvim; you say so once, the manager loads them in order.
• Lazy loading — plugins load on first use, not at startup. Eager-loaded plugins you rarely touch don't tax your nvim cold-start.
• Version pinning — a lockfile records the exact commit each plugin sits at. Reproduce a setup; roll back a bad update.
• One-command updates — refresh everything at once. See a changelog, decide, commit the lockfile.

The export promise of this curriculum hangs on these jobs. The init.lua you take home isn't a pile of folders — it's a declarative spec that, dropped into a fresh Neovim, reconstructs your entire editor from a single command.

The field of options

Plugin managers exist for every era of Vim and Neovim. Here's the honest 2026 lay of the land:

• vim-plug — the Vimscript-era classic. Works, widely deployed, but no native lazy loading and no Lua API. Fine if you're staying on Vim; out of step with modern Neovim ergonomics.
• packer.nvim — was the Lua default in 2022. Archived and unmaintained. Tutorials still reference it; don't start here.
• paq.nvim — minimalist. Clones plugins into the right folder and stops. No lazy loading, no profiler, no spec-as-data ergonomics.
• mini.deps — newer, part of the broader mini.nvim family. Smaller community, fewer tutorials assume it. Worth watching.
• lazy.nvim — Lua-native, lazy loading is first-class, has a built-in profiler UI, and it's what nearly every public Neovim config in 2026 is built on.

Why lazy.nvim wins

Three reasons this curriculum picked lazy.nvim — and they're the same reasons most modern Neovim configs land here:

• Lazy loading is first-class, not bolted on. The sub-100ms cold-startup goal you'll hit later in Row 2 only works because lazy.nvim defers plugins until they're actually needed. Other managers can be coaxed into similar behaviour; lazy treats it as the default.
• Lua-native API. Modern Neovim is configured in Lua. lazy specs are Lua tables — no language impedance, no string templating, no DSL to learn. The plugin spec is just a value.
• De-facto community default. In practical terms, this is the biggest one. Almost every blog post, dotfiles repo, plugin README, and starter config you'll read next assumes lazy.nvim. Learning it makes the entire Neovim ecosystem readable in a way no other choice does.

You're now ready to actually use it. The next lesson drops you into a Neovim with lazy.nvim pre-bootstrapped — open the :Lazy UI and see the field for yourself.