I feel like I have to migrate to a new (Neo)Vim package manager about once every 3 or so years. I think my path has been: pathogen -> Vundle -> vim-plug -> lazy.nvim. Hopefully, this the last VIM package manager?
I'm torn. I really like Lazy and have never minded having different package managers for Vim over the years. But having one blessed one is probably better long term, just like built-in LSP and Treesitter.
Apparently this has been a long-time goal of the Neovim project, but it isn't really explained why. It feels like bloat in a space where existing plugins did a fantastic job, but apparently some people disagreed with that.
Still primitive. But I'd love to drop lazy for this once they implement a differed load.
I love lazy.nvim. It's great no doubt. But recently I felt like the author is taking an aggressive user retention behavior by re-imprementing every useful open-source community plugins out there (like snack.nvim, mini.nvim). That's a kill-zone/copycat strategy. I don't get it.
I don't need this to be minimal, I'd love it to be the one true solution, niche requirements excepted.
I'm currently still using vim pack with git submodules because I can't be bothered to trawl through tens of GitHub projects to work out what's the best supported / most liked / currently recommended third-party nvim package manager.
Built a single file config with this after watching Sylvan Franklin and TJ DeVries a bit on YouTube and it has been great. Config junkies may need something more, but for a minimalist (and is minimalism not the essence of neovim?) it’s lovely.
Every time I see a something with the ability to import code from Git, especially if they allow specifying a branch (this pack even supports commit hashes), I wish they would document (and that more people would know) that they can "checkout" a branch at a specific time; because a lot of branches (vim plugins included) don't even bother with versioning.
ex: you can use this to checkout a repo @ a specific datetime:
> git checkout 'master@{2025-05-26 18:30:00}'
just doing my share to help people steer away from another leftPad disaster (or the xz apocalypse that almost was...)
I’ve migrated over to it - got about 12 plugins or so. No complaints so far! I don’t have strong opinions on whether my plugins are loaded lazily or not. Seems to work fine to get it done and get out of the way.
I'm really looking forward to this. I hope it helps push the nvim plugin community into lazy loading plugins by default instead of relying on a complex plugin manager like lazy. The nvim docs have a little note related to this[1].
I'm quite a fan of the nvim-neorocks plugin best practices as well[2]. In fact it seems like part of them got merged recently[3] hahaha.
Over the last decade i went thru 4 package managers. I always hoped for a builtin one. Over the years my package dep count has decresed radically. I think i use 4-6 plugins (and one theme) really on a daily basis. The rest is nice to haves i probably use once a month making them up for deletion.
I build neovim from source by myself, and maintain plugins as git submodules in pack/plugins/start (nvim automatically loads these at startup) and pack/plugins/opt (these are loaded manually) by myself. I have stuff like emmet, diffview.nvim, nvim-dap, etc loaded optionally when I want to use them. Status bar, LSP, Treesitter, and a few small tpope plugins are loaded on startup. I have a 500 line init.vim. I have a few local patches for some of the plugins.
This way, _nothing_ changes ever. That's how I want it.
I used to use astro.nvim (a few years back), then at one point I upgraded it and they had changed all the keybinds (even for basic shit like go to references IIRC), it was absolutely insane. I lost my shit and deleted the whole thing and moved to this setup. I will never use an nvim distro or update nvim plugins ever again. If I really want something I will git pull it myself (I'm looking out for nvim 12's ghost text feature for example). But in the general case, I'm done with any changes whatsoever. Not one byte.
I actually open-sourced my "approach" and documented it but I left it midway, if others are interested I might stop procrastinating and actually finish it.
It’s funny when you start a project and then find something so similar in the wild.
I’m writing a C package manager in exactly the same vein. Git based, no binaries, rolling release. It’s probably not such a coincidence, since I was inspired by Lazy in the first place.
You don’t really need a Vim plugin manager, especially if you use git for your dotfiles.
Installing a plugin merely requires placing its files (eg: cloning its repository) into a well-known location. You can just do that.
If you track your config with git, you can track plugins with submodules. This has the added advantage of pinning the exact version (and tracking that version in for).
Seems like every 3 months something new supersedes the incumbent. I’ve been using kickstart.nvim and maintaining parity with all the changes has been chaotic.
I recently migrated to it [1], no issues so far. It doesn’t have the many features Lazy.nvim has (e.g. lazy loading of plugins that can be triggered in various ways), but this is a tradeoff I am fine with.
I'm a long time vim user, but neovim with plugins is just not worth it for me. Something always breaks. I think neovim would do better if they started integrating the core plugins like LSP, tree sitter
34 comments
[ 3.0 ms ] story [ 42.4 ms ] threadApparently this has been a long-time goal of the Neovim project, but it isn't really explained why. It feels like bloat in a space where existing plugins did a fantastic job, but apparently some people disagreed with that.
I love lazy.nvim. It's great no doubt. But recently I felt like the author is taking an aggressive user retention behavior by re-imprementing every useful open-source community plugins out there (like snack.nvim, mini.nvim). That's a kill-zone/copycat strategy. I don't get it.
I'm currently still using vim pack with git submodules because I can't be bothered to trawl through tens of GitHub projects to work out what's the best supported / most liked / currently recommended third-party nvim package manager.
ex: you can use this to checkout a repo @ a specific datetime: > git checkout 'master@{2025-05-26 18:30:00}'
just doing my share to help people steer away from another leftPad disaster (or the xz apocalypse that almost was...)
I love Vim key bindings, and I'm happy to see the flagship of Vim keybindings improve.
I'm quite a fan of the nvim-neorocks plugin best practices as well[2]. In fact it seems like part of them got merged recently[3] hahaha.
[1] https://neovim.io/doc/user/lua-plugin.html#lua-plugin-lazy
[2] https://github.com/nvim-neorocks/nvim-best-practices
[3] https://github.com/neovim/neovim/pull/29073
This way, _nothing_ changes ever. That's how I want it.
I used to use astro.nvim (a few years back), then at one point I upgraded it and they had changed all the keybinds (even for basic shit like go to references IIRC), it was absolutely insane. I lost my shit and deleted the whole thing and moved to this setup. I will never use an nvim distro or update nvim plugins ever again. If I really want something I will git pull it myself (I'm looking out for nvim 12's ghost text feature for example). But in the general case, I'm done with any changes whatsoever. Not one byte.
I actually open-sourced my "approach" and documented it but I left it midway, if others are interested I might stop procrastinating and actually finish it.
I’m writing a C package manager in exactly the same vein. Git based, no binaries, rolling release. It’s probably not such a coincidence, since I was inspired by Lazy in the first place.
https://github.com/tspader/spn
Installing a plugin merely requires placing its files (eg: cloning its repository) into a well-known location. You can just do that.
If you track your config with git, you can track plugins with submodules. This has the added advantage of pinning the exact version (and tracking that version in for).
Should it provide to backup/install local plugins? I mean, probably I can move the directory with it into the correct destination.
[1] https://github.com/bpierre/dotfiles/blob/main/nvim/lua/packa...