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?

▲ trip-zip 5 days ago | parent | next [-]

Plug still gets the job done imo. But I'm also hopeful that since this one is builtin to the language it'll likely be end-game worthy for lots of users. I have tried it out and had a painless experience though I never did anything fancy like lazy offered.

▲ yoyohello13 5 days ago | parent | prev | next [-]

Luckily this is the built in, official, blessed one. So it’s likely going to be the most widely supported and available. (Maybe not most feature rich though)

▲ jauntywundrkind 5 days ago | parent | prev | next [-]

Lazy.nvim seems pretty triumphant. But yeah a lot of others are also supported by various plugins. Some unity would be nice, abstractly. But man, it's hard to have faith we're going to get as anything good fast and reliable as lazy.nvim. it could happen though!

▲

Lio 5 days ago | parent [-]

Every plugin manager I've used since Pathogen has seemed "triumphant" at the time. I think they've all been reliable enough and everytime I think well this will be the last time I change that.

I currently have a Packer config on one machine and Lazy on another and honestly don't know why I bothered switching to Lazy. What I really crave is simplicity so if NeoVim builds every thing in I think it will be good enough for me.

	▲	Nilithus 5 days ago \| parent [-]
		I switched from packer to lazy after I noticed the maintainer of packer stopped using packer in his neovim config. Also I believe he has now officially marked it as unmaintained and recommends lazy or pckr

▲ 0x457 5 days ago | parent | prev | next [-]

I started using nixvim. I think I gave up around vim-plug. Trying to maintain reliably working config across multiple machines and OS was a nightmare.

▲

colordrops 5 days ago | parent | next [-]

Nixvim is great. I got it configured with a flake and add it to all my machines. Nix lang is really suitable to composing neovim config.

	▲	0x457 4 days ago \| parent [-]
		Yup, I have a giant flake that configures all of my home linux and macos machines. Every machine gets more or less the same home-manager configuration applied, nixvim is split into its own flake.

▲

schonfinkel 5 days ago | parent | prev [-]

I've been using the "old school" approach of just leveraging neovim + huge list of `vimPlugins` in my Nix config, makes you about the myriad of package managers for vim/neovim.

Replacing it with nixvim is on my forever growing todo list.

▲ naniwaduni 5 days ago | parent | prev | next [-]

I tossed pathogen in favor of git submodules in ~/.vim/pack/*/start/ in 2017 and it's still like that.

▲

rand0m4r 5 days ago | parent [-]

same here - works great and never needed anything else.

	▲	freedomben 5 days ago \| parent [-]
		Same. I love vim and have no plans to leave, but I have no interest in being on the upgrade treadmill when my current system isn't broken. I've also had plugin updates break stuff, and it's a simple rollback in git back to a working state. I'm not sure how hard that is with these various plugin managers, but it's quite simple with git and I don't have to learn yet another tool/way of doing things.

▲ Aissen 5 days ago | parent | prev | next [-]

Just looked at my (private) dotfiles git history

- pathogen in 2011

- vundle in 2013

- vim-plug in 2017

Haven't moved since, Plug still does the job, even after I moved to neovim in 2021. Will probably move to the new built-in package manager once the dust has settled.

▲ motiejus 5 days ago | parent | prev | next [-]

in Nix it's the same for as long as I remember, both on NixOS and nix-managed home-manager on MacOS and Linux:

      neovim = {
        enable = true;
        vimAlias = true;
        vimdiffAlias = true;
        defaultEditor = true;
        plugins = [
          pkgs.vimPlugins.fugitive
          pkgs.vimPlugins.fzf-vim
          pkgs.vimPlugins.vim-gh-line
          pkgs.vimPlugins.vim-gutentags
          pkgs.vimPlugins.nvim-lspconfig
          pkgs.pkgs-unstable.vimPlugins.vim-go
          pkgs.pkgs-unstable.vimPlugins.zig-vim
        ];
        extraConfig = builtins.readFile ./vimrc;
        extraLuaConfig = builtins.readFile (pkgs.replaceVars ./dev.lua {
              inherit (pkgs) ripgrep;
            }).outPath;
      }

▲ lawn 5 days ago | parent | prev | next [-]

This is the FOMO speaking. You don't have to switch if you don't want to.

	▲	bravetraveler 5 days ago \| parent [-]
		+1. Configured my plugins years ago and have not cared about the mechanism at all. I might even have confused things and landed on two. Whatever. The result is what matters: I have extensions. In the exceedingly-rare event I do want to add one... overwhelmed with choice. "Have to" is entirely self-imposed

▲ f311a 5 days ago | parent | prev | next [-]

New package manager is pretty slow right now, it's like 200ms to load nvim with lazy vim vs 1 sec with Pack.

▲

christophilus 5 days ago | parent [-]

How many plugins do you have?

	▲	f311a 5 days ago \| parent [-]
		22

▲ rapind 5 days ago | parent | prev | next [-]

I’m literally just using git with vim.

▲ leephillips 5 days ago | parent | next [-]

Me too. I don’t understand why people think they need plugin managers. I just git clone the plugin into blah/blah/start and if I feel like updating one I do a git pull.

▲ gitaarik 5 days ago | parent | prev [-]

How do you keep your plugins up to date?

▲ tasuki 5 days ago | parent | next [-]

Why would you want to keep your plugins up to date? How do you prevent breakage?

I update my plugins when I want/need to.

▲

freedomben 5 days ago | parent [-]

Exactly. I update if I want a new feature or bug fix, but other than that I love the predictability of knowing nothing has changed, and when it does, exactly what changed. Being able to `git diff` and see what's new is wonderful

▲

vasac 5 days ago | parent [-]

How many plugins do you use? I probably have at least 70–80. Tracking what’s changed would be a job in itself, so I just update all plugins regularly, the same way I update IntelliJ IDEA, Homebrew, or Linux packages. If a package breaks often, then I (and most other people) simply stop using it.

▲

tasuki 4 days ago | parent [-]

> I probably have at least 70–80. Tracking what’s changed would be a job in itself, so I just update all plugins regularly

You and me have completely the opposite approach. You install everything you can get your hands on, I regularly prune my unused plugins to avoid bloat. I don't track what's changed: if I'm happy with a 10 year old version of a plugin, I don't see why I should update it.

> If a package breaks often, then I (and most other people) simply stop using it.

Unless there's a specific error message, how do you even know which package is responsible for the breakage? Ie a new visual glitch starts happening out of nowhere.

	▲	freedomben 4 days ago \| parent [-]
		I do the same thing. I have maybe 7 or 8 that I use, favoring built in functionality even if it's interior to what a plug-in might offer

▲ recursivecaveat 5 days ago | parent | prev | next [-]

I recently switched to lazy because I wanted to experiment with some more complex plugins, but the answer is just: I didn't keep them up to date. If you're using basic text-oriented stuff like fzf or surround how often is it going to improve in a meaningful way once it has reached its fully-formed state? If it did get a noticeable update its probably more likely to annoy me by breaking my config or muscle memory than anything.

▲ bayesianbot 5 days ago | parent | prev | next [-]

Am I the only one who thinks the way plugins are updated in lazy.nvim (and probably others) is a bit insane? It seems to just pull the latest commits. Every time I update, I feel one rogue commit away from someone stealing my keys. It definitely feels like the riskiest thing I do on my system. Or have I misunderstood something?

▲

behnamoh 5 days ago | parent | next [-]

Thanks, new fear unlocked for me :')

For me, lazy.nvim doesn't pull the latest commits automatically. I have to <leader>-L and SHIFT-U it. And I don't do it often exactly because if there's an issue with the plugins I hope it's caught by others and addressed before I update mine.

▲

sim7c00 5 days ago | parent | prev | next [-]

you are right to be worried about such practices. this is why i avoid these things entirely. its a bit more hastle but a lot less risk. once you have a good config u can just roll with that anyhow. but i guess in the same vein i dont use a lot of plugins.

the nr of times now people have been owned by rogue plugins via editors is rising each day...

▲

gitaarik 5 days ago | parent | prev | next [-]

So you mean you review all the plugin code before you add it? And when there's an update you review the changes?

▲

bayesianbot 5 days ago | parent | next [-]

So far I’ve just YOLO'd it. But if I install other software directly from git and the source isn’t fully reliable, I’ll usually at least check recent changes, or have codex take a look through the source, just like I read through PKGBUILDs when installing from AUR. It feels crazy that I then update LazyVim and suddenly pull in 150 new commits, some just minutes old, all with free access to my system.

▲

recursivecaveat 5 days ago | parent | prev | next [-]

If you manual update infrequently you are leaving a period for other people to get burned and flag issues before you pull the change, even if you don't look into a thing yourself.

	▲	ratrocket 5 days ago \| parent \| next [-]
		If your update is the simplest version, a "git pull" -- then you're incorporating commits that have not "stewed" long enough for anyone to be burned. You might win the lucky ticket! (Saying this as someone who rarely updates nvim plugins, out of forgetfulness, not principle, and when they are updated I believe it IS a simple "git pull"...)
	▲	gitaarik 5 days ago \| parent \| prev [-]
		With a plugin manager you can also update infrequently

▲

freedomben 5 days ago | parent | prev [-]

I mostly do, yes. There are exceptions for very mainstream and big plugins, but for the most part I do at least skim the new plugin code before committing it to my dotfiles repo. A nice thing about this ecosystem is for the most part, things don't change that quickly/often, and big refactors are quite rare

▲

5 days ago | parent | prev [-]

[deleted]

▲ wffurr 5 days ago | parent | prev | next [-]

I can’t recall the last time I updated a plugin. They are all working just fine.

	▲	gitaarik 5 days ago \| parent \| next [-]
		I add new language support from time to time. And sometimes I want to update a plugin because of a fix or new feature support.
	▲	kzrdude 5 days ago \| parent \| prev [-]
		I needed to update the lot when upgrading from neovim 0.10 to 0.11.x

▲ rapind 5 days ago | parent | prev | next [-]

I don't really. It's not like I use that many, and they are all sort of "complete". This isn't JS where you need to update and change your libraries every 5 minutes.

	▲	root_axis 5 days ago \| parent [-]
		The same logic applies to js. vim plugins see updates on a weekly basis, you don't have to upgrade anything if what you have works for you.

▲ t_mahmood 5 days ago | parent | prev | next [-]

Don't know about op, I had a script that would go through each plugin folder, check if it was a git folder, and pulled.

Now I use vimplug though

▲ porridgeraisin 5 days ago | parent [-]

  git submodule update

	▲	t_mahmood 5 days ago \| parent [-]
		Hmm, when I set it up, mercury was a thing, so, the script handled both. And, also, I was young, and that made me feel good :D

▲ Piraty 5 days ago | parent | prev | next [-]

git pull. too often i found breake so i inspect git-log message prior to update, git-bisect came in handy once

▲ OJFord 5 days ago | parent | prev [-]

'using git'

▲

dkdcio 5 days ago | parent [-]

what’s the issue? you just git clone the repo into the correct directory

▲

OJFord 5 days ago | parent | next [-]

There is no issue? I'm answering the question. This is how I do it too.

(There's sort of an issue in that I'd prefer to get it in neovim/lua, but that's not the point here.)

	▲	dkdcio 5 days ago \| parent [-]
		ohhh I misread what you were replying to! my bad

▲

gitaarik 5 days ago | parent | prev [-]

Yeah and if you have 10 plugins you have to go into each folder and git pull. Then you might want to write a script for that. Or just use a plugin manager ;)

▲

freedomben 5 days ago | parent | next [-]

I just wrote a simple bash script that has an array at the top with all the git remotes, and it iterates through them and git pulls (or clones if it doesn't exist yet). Took me like 10 minutes to write ~15 years ago and hasn't needed any changes. I can also trivially add a new entry to the array if I want to add a new plugin, or delete one if I'm not using it anymore. Then I also have a history of everything that changed so I can easily roll back if something breaks (which has happened several times)

▲

dboon 5 days ago | parent | prev [-]

git submodule update —init

	▲	gitaarik 5 days ago \| parent [-]
		Yeah, I also used submodules first. But removing a git submodule is a bit of a pain. Like 3 or 4 steps or something, which I usually need to look up how to do it again. And if you're experimenting with new plugins, trying them out, installing them and then removing them again, it's a lot easier with a plugin manager.

▲ sbinnee 5 days ago | parent | prev | next [-]

I have been staying on vim-plug where everyone seems to be moving on to lazy.vim. I was considering a weekend to migrate to lazy.vim sometime. But with this news, I might just have to wait for this plugin manager to drop.

▲ ComputerGuru 5 days ago | parent | prev | next [-]

Why? I’ve been using dein since it was released and haven’t needed to switch to anything (though I’ve noticed the momentum shifts quickly between different ones).

▲ burnt-resistor 5 days ago | parent | prev | next [-]

Similar here too. I'm on the lazy.nvim train too because it's componentized, powerful, and scalable. It would take me ages to get all of the stuff going that Just Works™ (pretty much) OOTB. Yes, even Copilot if you're into that sort of kinky code completion sharing with OpenAI/Microsoft everything you type.

▲

azemetre 5 days ago | parent [-]

I recently moved away from lazy.nvim to using vim.pack. You can check out my PR here:

https://github.com/azemetre/dotfiles/pull/61/files

It was worth it to me because I never relied on many features of lazy.nvim. The benefit of the approach linked in the PR is that it also defer's loading packages as well. The only one I initially load is alpha.nvim (a dashboard), everything else gets deferred. This brought down my startup time from around 300ms to sub 100ms.

▲

qiine 5 days ago | parent [-]

Just wanted to say I snatched your autocmd "go to last loc when opening a Buffer"

That's handy!

	▲	azemetre 5 days ago \| parent [-]
		No problem! One of my favorite things about vim is how modular it is and how simple it is to extend it too.

▲ film42 5 days ago | parent | prev | next [-]

I think I update Vundle like once every 3 years.

▲ theflyinghorse 5 days ago | parent | prev [-]

You're using an editor that is built to be configurable for people who enjoy endless configuration. This will not be the last config manager. You might as well ask JS community if Nextjs is the last JS framework

	▲	amelius 5 days ago \| parent [-]
		Yeah, this is like asking if "uv" will be the last package manager for Python.