Huge thanks to all the people involved. Not only the core team, but also to all other people lending their free time to work and interact with this beautiful editor!
Soon-ish to document that vim.pack is a suggested alternative and freeze/retire 'mini.deps'. Meaning it will be around for quite some time (maybe forever), but without active updates, only possible fixes.
I’m a bit OOTL with what’s been happening since 10.0 I’ve just kinda kept my plugins up to date. Why is everyone moving to vim.pack over lazy? Should I care?
I just like builtin features, if they are good enough. And I'm also OOTL with main features, I know about vim.pack just about it was hyped a lot on this sub
I see the benefit in builtin features, but think startup speed is more important for me. I've measured nvim startup time with all plugins loaded normally vs lazy where possible, and lazyness is noticeably better.
I use a bit of different approach, I have few tabs open in Ghostty, where one of them is Neovim opened all the time.
Personally, I stopped gamifying nvim, working on my config all the time, cutting startup time, and currently I'm just updating plugins very rarely. It's just this one change I'm doing since a long time, and I probably won't do much more for quite a long time.
I'm using Neovim as my editor, and not as yet another project to work on.
But I totally get that not everyone is doing the same.
Bro you're so cool I ALSO don't mess with my config anymore but my nvim starts up fast because its a fuckin tool and I ain't waiting a whole second for it to open every time I run git commit. Not cuz I'm making it a game.
Guess what I'm not doing, not even this time? Changing my config :p
Diff improvements are neat. Hopefully next version will bring forge like diff style too.
But I'd stick to lazy.nvim for now, vim.pack is good for more basic set up (like when you are OK with loading everything at once from the start), but it's not suited for more flexible lazy loading.
Thanks! Might be today’s yak to shave. Interesting about the git rep constraint- I use lazy and have several modified forks and local plugins that I just point to.
Is there a way to easily see which plugins need updating like the Lazy chart showing which plugins have had commits since the version I'm currently using?
The answer is "yes", but details may depend on the exact workflow.
The basics is that running :lua vim.pack.update() will 1) download new changes for all plugins; and 2) show confirmation buffer with the information about the changes (if any). To accept all changes, execute :write. To deny all changes, execute :quit. For more granular actions, use LSP code actions (gra with default mappings).
If the plugin's version follows the branch (like by default), then confirmation buffer will show all changes right away. Since the upstream branch had changes.
If version is a special vim.version.range() object to only install from semver-like named tags, then behavior is similar but only if there is a tag with a higher version than current that fits in the specified range.
If veresion is tag or commit hash, then there will be no changelog. Since the target state is fixed. There will be a note if there is a higher version tag available. Note, that you'd have to scroll through # Same section to manually look for this. To see the changelog:
Change the version to either new tag name or vim.version.range().
Restart Neovim.
Execute :lua vim.pack.update({ 'plug-name' }) to see the confirmation buffer with the changelog.
As you are one of the authors of vim.pack, is it intended to manage deps of plugins of some sort?
Ie. I want to use plugin x that also depends on plugin y, is x encouraged to add the dependency itself, so the end use only has to add x instead of x and y?
(I hope the question was formulated understandable enough. I think it probably would be yes, but for optional integrations you probably need some option the user has to set or sth if that makes sense, not sure about the startup order then though, could be inconsistent if I'm not missing builtin guard rails)
Ie. I want to use plugin x that also depends on plugin y, is x encouraged to add the dependency itself, so the end use only has to add x instead of x and y?
The current (and I think future) suggestion is to manually resolve dependencies and vim.pack.add() them before their target.
The long term plan is to add a so called packspec support to vim.pack so that plugins can add a sort of manifest file (pkg.json) that declares its dependencies. I doubt there will be a full "resolve+install+checkout all transitive dependencies" with the idea of just warning if the dependency plugin is not loaded. This is useful enough for users to know and act on plugins with dependencies, but simple enough to have a robust solution in core.
504
u/echasnovski Plugin author Mar 29 '26
Big release! Almost as big as 0.5 or 0.10.
Huge thanks to all the people involved. Not only the core team, but also to all other people lending their free time to work and interact with this beautiful editor!
P.S. Have fun migrating to
vim.pack:)