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.
The neovim model of using setup() makes lazy loading a bit trickier than traditional Vim.
Lazy loading is much easier with Vim’s model of configuring by setting variables. You just set variables in init.vim, and the plugin can auto-load when one of its functions is executed.
With lua this requires more orchestration; if many autocmd refer to the same plugin, they all need to explicitly remember to call setup().
Neovim provides the same mechanisms as Vim for Lua plugins.
The problem (and part of my motivation for writing the nvim-best-practices document) is that not enough plugins use them.
Edit: The Neovim setup antipattern is the Lua equivalent of writing Vimscript functions in autoload and asking users to call them in their configs instead of doing so automatically.
I don't know that I would call it an anti-pattern. It has several advantages over using a global variable:
- it avoids needing to create a global variable in the top level namespace
- if the setup is called lazily, then the user config can also perform other lazy operations at configuration time, including requiring other lua modules
- it allows you to pass a config object or function to your package manager, thus keeping your configuration of a plugin, and the code to require the plugin in the same place.
- it doesn't have the problem that you have to make sure you set the global variable before the plugin is loaded
- it is simpler to handle reconfiguring at runtime. The user just calls setup again. Whereas with a global variable, you don't know if/when the config has changed
- It's not at the top level namespace, it's usually in the `vim.g` or `vim.b` namespace. There's no more namespacing than with a Lua module + function.
- lazy.nvim's heuristics to auto-detect and invoke `setup` functions and pass "config objects" are a hack that could just as easily have been implemented around global config variables. This is a symptom of the problem, not a solution.
- If you don't need any code to require the plugin, there's also no need to keep the configuration and the code to require it in the same place.
- If a plugin is implemented correctly (by not making lazy loading the responsibility of the user), there's no need to worry about when the user sets the global variable.
- Most plugins' `setup` functions are idempotent. If you want to provide the ability to reconfigure your plugin at runtime, you can provide a `reload(opts)` function that sets the global config variable and then reinitialises the plugin. Or, you could add a metatable to the config variable that triggers a reload if the plugin has already been initialised. There's hardly ever a valid reason to force the coupling of configuration and initialisation on your plugin's users.
The settings variable convention is not good, uses random variable prefixes. A new convention is needed, then the ball can start rolling on that. Until then the lazy nvim and/or setup paradigm is useful.
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?
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.
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)
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!
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.
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
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.
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.
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.
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.
+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
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.
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
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.
> 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.
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.
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?
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.
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...
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.
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.
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"...)
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
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.
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 ;)
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)
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.
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.
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).
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.
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.
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
I have had zero issues thus far, also don't use too many plugins (like 50ish). It was way easier than expected, also had help from another person making the plugins load similarly to "lazy" as well. This setup is way way way faster than using lazy.nvim IME, especially my work computer where it would take 300 ms to load. Now it's around 80ms.
My bad, updated the links now. Reason for the passion is that I originally found out about neovim on hackernews where someone shared their dotfiles setup that used vim-plug with neovim. It looked simple to transition and I did.
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...)
Seems like a plausible idea but working with clocks my first question would be "whose clock is it". Is it repository defined clock? My clock? Git remote’s clock?
AFAIK this can be used for hashes, but friends don’t let friends use clocks in software developments (unless it’s last resort).
A plugin can spawn arbitrary processes so if neovim is not started in a sandbox (container, namespace, firejail...) they can basically do whatever your user has the right to do.
neovim (vim) plugins can make web requests, so you could steal secrets from a .env file being edited by, for example, making a LSP plugin active for .env files? According to my limited knowledge of LSP and how neovim plugins work, it should be possible
Could also just phone home everything a user edits using the text editor I bet.
Can someone tell me, when someone has a terminal buffer, using a vim plugin, could you potentially steal their root password when a user runs a sudo command?
And following up, could you, using that password, allow SSH connections and open ports in other system config files? Disable firewall? And potentially execute other commands using `:!` ?
You have the entire Lua language available in vim plugins, so you can just read all the files on the disk that the user has access to, you don't need to make an lsp plugin.
Executing shell commands is also possible, yes. Reading the root password is not possible because that's handled by an external program (forgot the specifics on Linux), but you could technically present a fake password prompt, and steal that.
I thought that gives master as of your pull time, not nearest commit to that time, which seems very confusing (it isn’t reproducible, except for yourself). I think you need a more complicated git log —before=time for any semblance of reproducibility
but thought I found a shortcut - which turns out is not really one, and like you said: confusing.
I can't edit my post, but in any case; the point being: it would be nice if import statements are closer to "github.com/google/uuid@YYYY-MM-DD" or in this case you can pass a date to version: "YYYY-MM-DD" and the library would run the uglier nested command above to import the proper version.
Easier for humans to parse, but introduces the threat vector of malicious attackers modifying the history and force submitting malicious code at or before a pinned time. That's why lock files exist.
SHA is still the way to go for those who are security sensitive.
Fair. If we're talking about documenting this feature, we should point out that SHA is immutable, while branches, tags, and dates are mutable references.
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).
> 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).
I did this for a year or so, with the motivation that submodules could replace all tool-specific package managers (for vim, tmux, zsh, etc.).
But honestly managing Git submodules felt like a chore compared to my old `vim-plug` setup. Basically because submodules are a neat concept but not implemented very ergonomically in Git. Eventually I just went back.
If someone has a setup using built-in vim pack that feels more ergonomic than vim-plug et al. then I’m very interested to hear.
I find myself enabling and disabling some plugins frequently and find it easy via the com config than the shell/filesystem . However, more importantly plugins can be activated easily based on file-type. Most plugin managers are anyway only a small wrapper around git, I guess.
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 think he's pretty well placed to implent good interfaces following his paradigm, noticeably different than some other authors. I like it, so I often think his take is the best.
Snacks picker is now the best picker, for example.
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
> I think neovim would do better if they started integrating the core plugins like LSP, tree sitter
That's exactly what they're doing.
Both tree-sitter and LSP are built in and the primary LSP/tree-sitter plugins only bundle default LSP configurations and tree-sitter queries respectively. They're also planning to include tree-sitter query bundling into Neovim natively somehow, to make it even less reliant on the nvim-treesitter plugin.
They recently simplified the LSP configuration and to configure a new LSP you basically do this:
I was the same and kept using vim for C/C++ development. vim-plug, gutentags (ctags manager), ALE did their job pretty well and I didn't bother to learn another way.
All that changed with web dev where you have to juggle with different syntaxes and tools... I decided I would just use a neovim distribution. I have tried many but Lunarvim (now inactive) and now Astronvim have served me well so far.
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.
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.
I followed the work of another neovimmer where he was able to replicate deferring with vim.pack. Brought my startup time down to sub 100ms.
Definitely worth it to me as it's one less "core" plugin to maintain. Having things like telescope or trouble are one thing, it's quite another to rely on a plugin that changes the way neovim interacts with loading.
I agree if it at least can match lazy.nvim in features, which it so far doesn't. Stuff like pinning plugin versions, notifying about breaking changes and actual lazy loading are very useful.
> - Update 'init.lua' for plugin to have version set to current commit hash. You can get it by running vim.pack.update({ 'plugin-name' }) and yanking the word describing current state (looks like abc12345).
I'm not criticizing it, just describing what I'd consider a level good for switching at least for me. It can be different for others and they might think they need less.
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.
I like the approach! I'd be interested in reading more. I might not fully adopt it but I m on a similar wavelength about stability. I don't want things to change unexpectedly, I just want my tools to just work consistently without surprises.
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.
@justinmk, thanks for all your work and leadership on neovim. I'm not excited about this feature, but in general I am excited about the changes I've seen in the project. Making a text editor is definitely not my life's ambition, but I'm glad you're taking up the challenge.
...
I don't really agree that "New users must look for a plugin manager and figure out how to install it". The only users who need to do that are the ones who have already found a plugin that they want to install, and which also doesn't provide installation instructions of its own. I don't agree that "Lack of a declarative way to specify plugins" is a valid problem, since this problem is actually introduced by bundling a plugin manager.
And this justification for creating the feature completely ignores the several high-quality existing, unbundled implementations of plugin managers. The installation of Lazy.nvim is entirely within your nvim init files, demonstrating that 3rd-party plugin managers can have simple installation instructions.
The bundled package manager also makes some trade-offs that 3rd-party ones don't have to make (e.g. support for non-git plugins). This is addressable, like the lack of lockfiles, automatic dependency management, and re-implementing every other feature that existing plugins already provide. That's why this is bloat. This task is better-served outside of the core project.
When problems get solved, the remaining problems become more salient. The most salient feedback we get in the last 3+ years is that the "getting started" UX has too much friction. (And this affects old users too, whenever I install Nvim on a new machine without my bag-of-tricks, I notice where friction is.)
For most users that want LSP, or even just to try Nvim for 2 minutes to see what it can do, it's not acceptable that our intro docs have to say "go here or there to install this or that plugin manager, and read their docs, then come back...".
Being able to say "add vim.pack.add(http://...) to your config, then :restart", is a complete answer.
vim.pack is relatively tiny (low maintenance), and zero performance cost for users that don't use it. Not bloat.
It's the opposite of bloat, because it allows us to more often choose "runtime-dependencies", instead of "shipping the universe" in the default build. That's a very welcome "release valve".
- Example of "shipping the universe": Vim's 1000+ builtin syntax files, ftplugins, etc.
- Example of "runtime-dependencies": nvim-lspconfig, treesitter parsers.
> The only users who need to do that are the ones who have already found a plugin that they want to install,
You skipped some steps.
> automatic dependency management
None of the existing plugin managers do that, except luarocks.
You joke, but a colleague tried to get me using nvim a few months ago, and after installing all the stuff he recommended, my first impression was that I was running emacs. It was busy, there were extra buffers all over the place, things kept popping up as I typed, and I wasn’t clear on how to get to normal mode. In sure this has as much to do with his config, which I copied without understanding it, as it does with nvim itself, but it felt very unfamiliar.
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.
Offtopic, and no one asked, but I'm going to advertise anyway: Helix is a good alternative to (neo)vim for anyone who wants a terminal editor with vimotions(ish) but doesn't like configuring or scripting. That was the selling point that made me stay with it: The out-of-the-box experience was close enough to what I was hoping to end at but gave up with neovim due to the hassle required. It is opinionated of course, but the default behavior and appearance of Helix felt much more appropriate than that of neovim.
I'm a Neovim user but I have to agree with the recommendation. If you've wanted to check out vim/emacs but were nervous Helix is a good place to start.
I do wish there was at least the option to use vim keybindings in Helix though. The Helix keybindings are mostly the same but just different enough to be annoying if you're already used to vim.
Someone else mentioned evil-helix if you really want those keybindings but, admittedly, I think the different keybindings (and more specifically the select then operate model) are a major point of why helix (and its inspiration, kakoune) exists.
I actually like Helix a lot too, but it is different than (neo)vim in a lot of significant ways. It feels like alternate-universe vim more than just better defaults. It also doesn't just not require scripting, it doesn't support scripting (yet). Very interesting in its own right but it might not be what you want if you're familiar with (neo)vim already.
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.
On the neovim subreddit one of the core maintainers said that relying on users to lazy load plugins is an extremely poor practice and something that should be done by the author's of said plugins. It is just a matter of how you initialize your plugin/name-of-plugin.lua file.
Don't know if it helps but I recently migrated to vim.pack. With another neovimmer he helped me create a defer function and pack update. The only plugin I initially load is a dashboard while deferring everything else. Brought my startup time to sub 100ms.
I don't understand that argument (and I've heard it several times), see comment below about plugins dependencies. I.e. that argument is OK for isolated cases, not for more complex dependency graph.
It doesn't answer your question about plugin dependencies (although vim.pack lets you handle this), but it might give you more insight on where vim.pack will go in the future.
Depending on the number of plugins you have, you may not notice the difference in practice. I certainly don’t but I’m very much on the minimal side of things. This all said I’m definitely of the school of thought that plugin developers should be responsible for ensuring their plugins are lazy loaded, rather than leaving it up to the user, who is not as well placed to make the decision.
Well, it might work for individual plugins, but it can't work for when you use plugins as extensions for other plugins. How would plugin A know it has to load B (which is an extension of A) as a prerequisite for [lazy] loading itself?
Basically, only plugin manager can have a sane graph of plugins dependencies and know how to load them because that graph is in the end defined by the user (for the plugin manager) and plugins themselves have no clue what user might want.
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.
More news on neovim than vim these days, including this one. I wonder if I should switch to neovim, as more AI related plugins are neovim only. In the meantime, Vim has served me fine so far.
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.
>Problem:
>
>New users must look for a plugin manager and figure out how to install it.
> - Nvim documentation should be able to give a one-liner to install (non-builtin) plugin managers and plugins.
>
> Lack of a declarative way to specify plugins.
> - Lets Nvim reason about dependency ordering / transitivity.
> - Lets crawlers build a package index.
> - [packspec](https://github.com/neovim/packspec) adds potential to leverage NPM tooling (and possibly infrastructure).
I find it weird to not have one, given the ubiquity of plugins in (neo)vim. These editor are self-proclaimed "super easy to extend/program", until now it was awkward to need a third party plugin manager to "extend" them (the vast majority of people use plugins and don't extend all the functionalities with their own code). Plus 0.12 is said to be "The year of Nvim OOTB": https://neovim.io/roadmap/
A neovim plugin manager is essentially a git clone tool that knows how to execute a setup function. This aspect of plugin management is the same for all plugin managers in neovim. The goal is to have something that mostly works as-is but other plugins managers can potentially build off of to support advanced features like lazy loading.
100% agree. I started over in 2022 or 2023 after 10 years of Vim cruft building up by moving to a Lua-based Neovim setup with Packer (now-unmaintained package manager). It was definitely an improvement, and I was impressed by how smooth and easy it was to get set up with a modern, fully-featured Neovim setup. However, I felt a little uneasy with all the packages needed to get a really good LSP setup without a ton of work (lsp-zero, lspconfig, etc).
Deleted my ~/.config/nvim/ directory the other day and started again just to see what the experience was like with modern Neovim capabilities, and it was so much easier!
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.
Can't say I'm looking forward to migrating from lazy.nvim, tbh... Can anyone tell me what this does better than lazy? I can't really tell from the docs alone
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.
Given how many configs being shared here which include their own half-baked (no offence!) `add_plugin` functions which replicate traditional vim plugin managers, there's definitely still room for something like Lazy which just wraps `vim.pack`
Not sure what you mean by this. Do you mean for versioning requiring `vX.Y.Z` tags? That's quite standard (linux kernel does this). Otherwise it defaults to main/master branch which is also basically standard depending on when the repo was made...
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.
[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
The neovim model of using setup() makes lazy loading a bit trickier than traditional Vim.
Lazy loading is much easier with Vim’s model of configuring by setting variables. You just set variables in init.vim, and the plugin can auto-load when one of its functions is executed.
With lua this requires more orchestration; if many autocmd refer to the same plugin, they all need to explicitly remember to call setup().
Neovim provides the same mechanisms as Vim for Lua plugins. The problem (and part of my motivation for writing the nvim-best-practices document) is that not enough plugins use them.
Edit: The Neovim setup antipattern is the Lua equivalent of writing Vimscript functions in autoload and asking users to call them in their configs instead of doing so automatically.
I don't know that I would call it an anti-pattern. It has several advantages over using a global variable:
- it avoids needing to create a global variable in the top level namespace
- if the setup is called lazily, then the user config can also perform other lazy operations at configuration time, including requiring other lua modules
- it allows you to pass a config object or function to your package manager, thus keeping your configuration of a plugin, and the code to require the plugin in the same place.
- it doesn't have the problem that you have to make sure you set the global variable before the plugin is loaded
- it is simpler to handle reconfiguring at runtime. The user just calls setup again. Whereas with a global variable, you don't know if/when the config has changed
- It's not at the top level namespace, it's usually in the `vim.g` or `vim.b` namespace. There's no more namespacing than with a Lua module + function.
- global configuration variables don't have to be tables. They can be a union of `table | fun():table`, which enables laziness. [rustaceanvim does this, for example](https://github.com/mrcjkb/rustaceanvim/blob/12504405821c0587...).
- lazy.nvim's heuristics to auto-detect and invoke `setup` functions and pass "config objects" are a hack that could just as easily have been implemented around global config variables. This is a symptom of the problem, not a solution.
- If you don't need any code to require the plugin, there's also no need to keep the configuration and the code to require it in the same place.
- If a plugin is implemented correctly (by not making lazy loading the responsibility of the user), there's no need to worry about when the user sets the global variable.
- Most plugins' `setup` functions are idempotent. If you want to provide the ability to reconfigure your plugin at runtime, you can provide a `reload(opts)` function that sets the global config variable and then reinitialises the plugin. Or, you could add a metatable to the config variable that triggers a reload if the plugin has already been initialised. There's hardly ever a valid reason to force the coupling of configuration and initialisation on your plugin's users.
The settings variable convention is not good, uses random variable prefixes. A new convention is needed, then the ball can start rolling on that. Until then the lazy nvim and/or setup paradigm is useful.
You don"t have to use a separate variable prefix for each config option. A plugin's config variable can just be a table/dictionary.
We need a uniform convention for this. Hopefully then vim.pack enforces something.
AFAIK using setup() is actually a cargo-cult practice and discouraged by the Neovim maintainers.
echasnovski seems to like it (and he's a maintainer I think)
His use case is mini.nvim, a huge bundle of plugins where you most likely don't want each plugin initialising automatically.
He and I are on very opposite ends of the "setup spectrum", but we have found common ground, which is that you shouldn't cargo cult it: https://github.com/neovim/neovim/pull/35600/files
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?
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.
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)
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!
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.
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
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.
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.
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.
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.
I tossed pathogen in favor of git submodules in ~/.vim/pack/*/start/ in 2017 and it's still like that.
same here - works great and never needed anything else.
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.
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.
in Nix it's the same for as long as I remember, both on NixOS and nix-managed home-manager on MacOS and Linux:
This is the FOMO speaking. You don't have to switch if you don't want to.
+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
New package manager is pretty slow right now, it's like 200ms to load nvim with lazy vim vs 1 sec with Pack.
How many plugins do you have?
22
I’m literally just using git with vim.
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.
How do you keep your plugins up to date?
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.
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
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.
> 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.
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
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.
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?
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.
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...
So you mean you review all the plugin code before you add it? And when there's an update you review the changes?
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.
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.
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"...)
With a plugin manager you can also update infrequently
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
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.
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.
I can’t recall the last time I updated a plugin. They are all working just fine.
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.
I needed to update the lot when upgrading from neovim 0.10 to 0.11.x
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
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
git pull. too often i found breake so i inspect git-log message prior to update, git-bisect came in handy once
'using git'
what’s the issue? you just git clone the repo into the correct directory
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.)
ohhh I misread what you were replying to! my bad
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 ;)
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)
git submodule update —init
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.
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.
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).
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.
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.
Just wanted to say I snatched your autocmd "go to last loc when opening a Buffer"
That's handy!
No problem! One of my favorite things about vim is how modular it is and how simple it is to extend it too.
I think I update Vundle like once every 3 years.
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
Yeah, this is like asking if "uv" will be the last package manager for Python.
If it helps any neovimmers I recently migrated away from lazy.nvim to just using vim.pack:
https://github.com/azemetre/dotfiles/pull/61/files
I have had zero issues thus far, also don't use too many plugins (like 50ish). It was way easier than expected, also had help from another person making the plugins load similarly to "lazy" as well. This setup is way way way faster than using lazy.nvim IME, especially my work computer where it would take 300 ms to load. Now it's around 80ms.
You're linking this all over the place so heads up, it links to an unrelated file in the diff.
My bad, updated the links now. Reason for the passion is that I originally found out about neovim on hackernews where someone shared their dotfiles setup that used vim-plug with neovim. It looked simple to transition and I did.
Just trying to share the love.
[dead]
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...)
Seems like a plausible idea but working with clocks my first question would be "whose clock is it". Is it repository defined clock? My clock? Git remote’s clock?
AFAIK this can be used for hashes, but friends don’t let friends use clocks in software developments (unless it’s last resort).
I’m curious. What’s the risk of a supply chain attack? What are the privileges of a VIM plugin?
A plugin can spawn arbitrary processes so if neovim is not started in a sandbox (container, namespace, firejail...) they can basically do whatever your user has the right to do.
Pretty big supply chain risks here.
And often times sandboxing it is hard.
E.g.: what do you use to edit ~/.ssh/config or ~/.profile?
neovim (vim) plugins can make web requests, so you could steal secrets from a .env file being edited by, for example, making a LSP plugin active for .env files? According to my limited knowledge of LSP and how neovim plugins work, it should be possible
Could also just phone home everything a user edits using the text editor I bet.
Can someone tell me, when someone has a terminal buffer, using a vim plugin, could you potentially steal their root password when a user runs a sudo command?
And following up, could you, using that password, allow SSH connections and open ports in other system config files? Disable firewall? And potentially execute other commands using `:!` ?
You have the entire Lua language available in vim plugins, so you can just read all the files on the disk that the user has access to, you don't need to make an lsp plugin.
Executing shell commands is also possible, yes. Reading the root password is not possible because that's handled by an external program (forgot the specifics on Linux), but you could technically present a fake password prompt, and steal that.
Anything a user application can do
I thought that gives master as of your pull time, not nearest commit to that time, which seems very confusing (it isn’t reproducible, except for yourself). I think you need a more complicated git log —before=time for any semblance of reproducibility
Good catch, you are correct. I initially was going post the actual command for checking out a branch at a time:
> git checkout $(git rev-list -1 --before="YYYY-MM-DD" master)
but thought I found a shortcut - which turns out is not really one, and like you said: confusing.
I can't edit my post, but in any case; the point being: it would be nice if import statements are closer to "github.com/google/uuid@YYYY-MM-DD" or in this case you can pass a date to version: "YYYY-MM-DD" and the library would run the uglier nested command above to import the proper version.
Why not by SHA?
Dates make pinning easier than looking up a SHA
Easier for humans to parse, but introduces the threat vector of malicious attackers modifying the history and force submitting malicious code at or before a pinned time. That's why lock files exist.
SHA is still the way to go for those who are security sensitive.
Fair. If we're talking about documenting this feature, we should point out that SHA is immutable, while branches, tags, and dates are mutable references.
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).
> 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).
I did this for a year or so, with the motivation that submodules could replace all tool-specific package managers (for vim, tmux, zsh, etc.).
But honestly managing Git submodules felt like a chore compared to my old `vim-plug` setup. Basically because submodules are a neat concept but not implemented very ergonomically in Git. Eventually I just went back.
If someone has a setup using built-in vim pack that feels more ergonomic than vim-plug et al. then I’m very interested to hear.
I find myself enabling and disabling some plugins frequently and find it easy via the com config than the shell/filesystem . However, more importantly plugins can be activated easily based on file-type. Most plugin managers are anyway only a small wrapper around git, I guess.
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.
And then ditching those packages unmaintained (like snacks).
// mini.nvim is a completely different author though and doesn't have to do much with lazy
The mini.nvim maintainer is the one who did a lot of the work for pack I believe:
https://github.com/neovim/neovim/pulls?q=is%3Apr+pack+is%3Ac...
I believe folkes is just on vacation. Hardly ditched.
Yeah last commit on snacks was only like 6 months ago. Reasonable vacation time for an independently wealthy guy.
I'm a bit bummed too - I switched a few plugins to snacks.nvim and now I have no idea if they are going to be maintained.
Could also be done and not had a reason to update.
There are quite a few bugs and open issues, and open MRs. So done seems unlikely
I think he's pretty well placed to implent good interfaces following his paradigm, noticeably different than some other authors. I like it, so I often think his take is the best.
Snacks picker is now the best picker, for example.
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
> I think neovim would do better if they started integrating the core plugins like LSP, tree sitter
That's exactly what they're doing.
Both tree-sitter and LSP are built in and the primary LSP/tree-sitter plugins only bundle default LSP configurations and tree-sitter queries respectively. They're also planning to include tree-sitter query bundling into Neovim natively somehow, to make it even less reliant on the nvim-treesitter plugin.
They recently simplified the LSP configuration and to configure a new LSP you basically do this:
And then in the "LspAttach" autocmd you can define your LSP specific keymaps for example.> And then in the "LspAttach" autocmd you can define your LSP specific keymaps for example.
If you want. It also now ships with most auto-mapped.
I was the same and kept using vim for C/C++ development. vim-plug, gutentags (ctags manager), ALE did their job pretty well and I didn't bother to learn another way.
All that changed with web dev where you have to juggle with different syntaxes and tools... I decided I would just use a neovim distribution. I have tried many but Lunarvim (now inactive) and now Astronvim have served me well so far.
Same, but I'm guessing it'll settle down in the next 5-10 years.
I’ve been using it for awhile, no issues: https://erock-git-dotfiles.pgs.sh/tree/main/item/dot_config/...
That is a thing of beauty.
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.
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.
I recently migrated from lazy.nvim to vim.pack and it was way easier than expected:
https://github.com/azemetre/dotfiles/pull/61/files
I followed the work of another neovimmer where he was able to replicate deferring with vim.pack. Brought my startup time down to sub 100ms.
Definitely worth it to me as it's one less "core" plugin to maintain. Having things like telescope or trouble are one thing, it's quite another to rely on a plugin that changes the way neovim interacts with loading.
I agree if it at least can match lazy.nvim in features, which it so far doesn't. Stuff like pinning plugin versions, notifying about breaking changes and actual lazy loading are very useful.
It has pinning already
> Freeze plugin from being updated:
> - Update 'init.lua' for plugin to have version set to current commit hash. You can get it by running vim.pack.update({ 'plugin-name' }) and yanking the word describing current state (looks like abc12345).
> - :restart.
That's good
It feels a bit dishonest to criticise an unreleased development build for a lack of features
I'm not criticizing it, just describing what I'd consider a level good for switching at least for me. It can be different for others and they might think they need less.
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.
I like the approach! I'd be interested in reading more. I might not fully adopt it but I m on a similar wavelength about stability. I don't want things to change unexpectedly, I just want my tools to just work consistently without surprises.
This is the original issue that added this: https://github.com/neovim/neovim/issues/20893
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.
It is explained in that issue: https://github.com/neovim/neovim/issues/20893#issuecomment-1...
@justinmk, thanks for all your work and leadership on neovim. I'm not excited about this feature, but in general I am excited about the changes I've seen in the project. Making a text editor is definitely not my life's ambition, but I'm glad you're taking up the challenge.
...
I don't really agree that "New users must look for a plugin manager and figure out how to install it". The only users who need to do that are the ones who have already found a plugin that they want to install, and which also doesn't provide installation instructions of its own. I don't agree that "Lack of a declarative way to specify plugins" is a valid problem, since this problem is actually introduced by bundling a plugin manager.
And this justification for creating the feature completely ignores the several high-quality existing, unbundled implementations of plugin managers. The installation of Lazy.nvim is entirely within your nvim init files, demonstrating that 3rd-party plugin managers can have simple installation instructions.
The bundled package manager also makes some trade-offs that 3rd-party ones don't have to make (e.g. support for non-git plugins). This is addressable, like the lack of lockfiles, automatic dependency management, and re-implementing every other feature that existing plugins already provide. That's why this is bloat. This task is better-served outside of the core project.
When problems get solved, the remaining problems become more salient. The most salient feedback we get in the last 3+ years is that the "getting started" UX has too much friction. (And this affects old users too, whenever I install Nvim on a new machine without my bag-of-tricks, I notice where friction is.)
For most users that want LSP, or even just to try Nvim for 2 minutes to see what it can do, it's not acceptable that our intro docs have to say "go here or there to install this or that plugin manager, and read their docs, then come back...".
Being able to say "add vim.pack.add(http://...) to your config, then :restart", is a complete answer.
vim.pack is relatively tiny (low maintenance), and zero performance cost for users that don't use it. Not bloat.
It's the opposite of bloat, because it allows us to more often choose "runtime-dependencies", instead of "shipping the universe" in the default build. That's a very welcome "release valve".
- Example of "shipping the universe": Vim's 1000+ builtin syntax files, ftplugins, etc.
- Example of "runtime-dependencies": nvim-lspconfig, treesitter parsers.
> The only users who need to do that are the ones who have already found a plugin that they want to install,
You skipped some steps.
> automatic dependency management
None of the existing plugin managers do that, except luarocks.
M-x package-list-packages :)
You joke, but a colleague tried to get me using nvim a few months ago, and after installing all the stuff he recommended, my first impression was that I was running emacs. It was busy, there were extra buffers all over the place, things kept popping up as I typed, and I wasn’t clear on how to get to normal mode. In sure this has as much to do with his config, which I copied without understanding it, as it does with nvim itself, but it felt very unfamiliar.
> and I wasn’t clear on how to get to normal mode.
You need to ditch your heretical friend if he has broken the Holy Commandment of <Esc> to get to Normal mode.
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.
Vimotheé!!
Discovered this guy recently while looking for a new vim.pack config. He's quite funny.
Link to src?
https://youtu.be/xGkL2N8w0H4?si=_U9rFhZM50Dg4cVw
Offtopic, and no one asked, but I'm going to advertise anyway: Helix is a good alternative to (neo)vim for anyone who wants a terminal editor with vimotions(ish) but doesn't like configuring or scripting. That was the selling point that made me stay with it: The out-of-the-box experience was close enough to what I was hoping to end at but gave up with neovim due to the hassle required. It is opinionated of course, but the default behavior and appearance of Helix felt much more appropriate than that of neovim.
I'm a Neovim user but I have to agree with the recommendation. If you've wanted to check out vim/emacs but were nervous Helix is a good place to start.
I do wish there was at least the option to use vim keybindings in Helix though. The Helix keybindings are mostly the same but just different enough to be annoying if you're already used to vim.
Edit: typo
Someone else mentioned evil-helix if you really want those keybindings but, admittedly, I think the different keybindings (and more specifically the select then operate model) are a major point of why helix (and its inspiration, kakoune) exists.
I haven't used it, but I've seen people speak well about evil helix https://evil-helix.github.io/
I actually like Helix a lot too, but it is different than (neo)vim in a lot of significant ways. It feels like alternate-universe vim more than just better defaults. It also doesn't just not require scripting, it doesn't support scripting (yet). Very interesting in its own right but it might not be what you want if you're familiar with (neo)vim already.
I still have to interact with files on servers I don't control, so I still need to keep basic vim motions in my working set memory unfortunately
Can I use wasd for my movement keys?
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.
[1] https://github.com/bpierre/dotfiles/blob/main/nvim/lua/packa...
From the name I initially assumed that it's about adding 'packs' (maintained group of plugins) similar to AstroNVim community packs [1]
[1] https://github.com/AstroNvim/astrocommunity/tree/main/lua/as...
Neat, but it's missing ability to lazy load plugins. I'm using lazy.nvim which is both lazy loader and update manager and it's really great.
On the neovim subreddit one of the core maintainers said that relying on users to lazy load plugins is an extremely poor practice and something that should be done by the author's of said plugins. It is just a matter of how you initialize your plugin/name-of-plugin.lua file.
Don't know if it helps but I recently migrated to vim.pack. With another neovimmer he helped me create a defer function and pack update. The only plugin I initially load is a dashboard while deferring everything else. Brought my startup time to sub 100ms.
https://github.com/azemetre/dotfiles/pull/61/files
I don't understand that argument (and I've heard it several times), see comment below about plugins dependencies. I.e. that argument is OK for isolated cases, not for more complex dependency graph.
This is the reddit thread where the lead of the project talks about it:
https://www.reddit.com/r/neovim/comments/1n2nax0/why_vimpack...
It doesn't answer your question about plugin dependencies (although vim.pack lets you handle this), but it might give you more insight on where vim.pack will go in the future.
Depending on the number of plugins you have, you may not notice the difference in practice. I certainly don’t but I’m very much on the minimal side of things. This all said I’m definitely of the school of thought that plugin developers should be responsible for ensuring their plugins are lazy loaded, rather than leaving it up to the user, who is not as well placed to make the decision.
Well, it might work for individual plugins, but it can't work for when you use plugins as extensions for other plugins. How would plugin A know it has to load B (which is an extension of A) as a prerequisite for [lazy] loading itself?
Basically, only plugin manager can have a sane graph of plugins dependencies and know how to load them because that graph is in the end defined by the user (for the plugin manager) and plugins themselves have no clue what user might want.
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.
https://github.com/tspader/spn
Neovim is really excellent, it's so good that they are adding a package manager. Loving this.
I've been very happy with Paq [1] which is essentially a lightweight wrapper around git pull.
[1] https://github.com/savq/paq-nvim
More news on neovim than vim these days, including this one. I wonder if I should switch to neovim, as more AI related plugins are neovim only. In the meantime, Vim has served me fine so far.
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.
One step closer to having all the features of Emacs. :flex:
I love Vim key bindings, and I'm happy to see the flagship of Vim keybindings improve.
Does anyone know what’s the ground they want to make a builtin plugin manager? Did they think there should be some sort of standard?
>Problem: > >New users must look for a plugin manager and figure out how to install it. > - Nvim documentation should be able to give a one-liner to install (non-builtin) plugin managers and plugins. > > Lack of a declarative way to specify plugins. > - Lets Nvim reason about dependency ordering / transitivity. > - Lets crawlers build a package index. > - [packspec](https://github.com/neovim/packspec) adds potential to leverage NPM tooling (and possibly infrastructure).
https://github.com/neovim/neovim/issues/20893#issuecomment-1...
I find it weird to not have one, given the ubiquity of plugins in (neo)vim. These editor are self-proclaimed "super easy to extend/program", until now it was awkward to need a third party plugin manager to "extend" them (the vast majority of people use plugins and don't extend all the functionalities with their own code). Plus 0.12 is said to be "The year of Nvim OOTB": https://neovim.io/roadmap/
A neovim plugin manager is essentially a git clone tool that knows how to execute a setup function. This aspect of plugin management is the same for all plugin managers in neovim. The goal is to have something that mostly works as-is but other plugins managers can potentially build off of to support advanced features like lazy loading.
They're trying to improve "setup experience" - see https://m.youtube.com/watch?v=Nq2T28_ILxc (I forget the timestamp and exact phrasing)
The new LSP api is actually great. Makes the whole setup way easier. They’re really doing great work.
100% agree. I started over in 2022 or 2023 after 10 years of Vim cruft building up by moving to a Lua-based Neovim setup with Packer (now-unmaintained package manager). It was definitely an improvement, and I was impressed by how smooth and easy it was to get set up with a modern, fully-featured Neovim setup. However, I felt a little uneasy with all the packages needed to get a really good LSP setup without a ton of work (lsp-zero, lspconfig, etc).
Deleted my ~/.config/nvim/ directory the other day and started again just to see what the experience was like with modern Neovim capabilities, and it was so much easier!
Thanks for sharing
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.
Can't say I'm looking forward to migrating from lazy.nvim, tbh... Can anyone tell me what this does better than lazy? I can't really tell from the docs alone
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.
Well kickstart.nvim is a template for your own configuration, not a distribution. You're not supposed to update it.
Nice.
Should it provide to backup/install local plugins? I mean, probably I can move the directory with it into the correct destination.
Plan to switch from vim-plug to this one, hopefully wont have to change again
Given how many configs being shared here which include their own half-baked (no offence!) `add_plugin` functions which replicate traditional vim plugin managers, there's definitely still room for something like Lazy which just wraps `vim.pack`
I’m disappointed that it requires the plugins to have a specific scheme for naming branches, so it won’t be compatible with all plugins.
Not sure what you mean by this. Do you mean for versioning requiring `vX.Y.Z` tags? That's quite standard (linux kernel does this). Otherwise it defaults to main/master branch which is also basically standard depending on when the repo was made...
> Do you mean for versioning requiring `vX.Y.Z` tags?
That, and also it has to be specifically Semantic Versioning.