> 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.
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.
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!
https://github.com/neovim/neovim/issues/20893#issuecomment-1...
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.
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://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.
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.
...
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.
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.
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.
// mini.nvim is a completely different author though and doesn't have to do much with lazy
https://github.com/neovim/neovim/pulls?q=is%3Apr+pack+is%3Ac...
Snacks picker is now the best picker, for example.
You need to ditch your heretical friend if he has broken the Holy Commandment of <Esc> to get to Normal mode.
I'm currently still using vim pack with git submodules because I can't be bothered to trawl through tens of GitHub projects to work out what's the best supported / most liked / currently recommended third-party nvim package manager.
ex: you can use this to checkout a repo @ a specific datetime: > git checkout 'master@{2025-05-26 18:30:00}'
just doing my share to help people steer away from another leftPad disaster (or the xz apocalypse that almost was...)
SHA is still the way to go for those who are security sensitive.
Pretty big supply chain risks here.
E.g.: what do you use to edit ~/.ssh/config or ~/.profile?
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 `:!` ?
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.
> 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.
AFAIK this can be used for hashes, but friends don’t let friends use clocks in software developments (unless it’s last resort).
I love Vim key bindings, and I'm happy to see the flagship of Vim keybindings improve.
I'm quite a fan of the nvim-neorocks plugin best practices as well[2]. In fact it seems like part of them got merged recently[3] hahaha.
[1] https://neovim.io/doc/user/lua-plugin.html#lua-plugin-lazy
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().
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.
- 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
- 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.
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
This way, _nothing_ changes ever. That's how I want it.
I used to use astro.nvim (a few years back), then at one point I upgraded it and they had changed all the keybinds (even for basic shit like go to references IIRC), it was absolutely insane. I lost my shit and deleted the whole thing and moved to this setup. I will never use an nvim distro or update nvim plugins ever again. If I really want something I will git pull it myself (I'm looking out for nvim 12's ghost text feature for example). But in the general case, I'm done with any changes whatsoever. Not one byte.
I actually open-sourced my "approach" and documented it but I left it midway, if others are interested I might stop procrastinating and actually finish it.
I’m writing a C package manager in exactly the same vein. Git based, no binaries, rolling release. It’s probably not such a coincidence, since I was inspired by Lazy in the first place.
That, and also it has to be specifically Semantic Versioning.
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).
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.
Should it provide to backup/install local plugins? I mean, probably I can move the directory with it into the correct destination.
[1] https://github.com/bpierre/dotfiles/blob/main/nvim/lua/packa...
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:
vim.lsp.config("expert", {
cmd = { "expert" },
root_markers = { "mix.exs", ".git" },
filetypes = { "elixir", "eelixir", "heex" },
})
vim.lsp.enable("expert")
If you want. It also now ships with most auto-mapped.
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.
[1] https://github.com/AstroNvim/astrocommunity/tree/main/lua/as...
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.
Just trying to share the love.
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
bikeshaving•2d ago
trip-zip•2d ago
jauntywundrkind•2d ago
Lio•2d ago
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•2d ago
f311a•2d ago
christophilus•2d ago
f311a•2d ago
yoyohello13•2d ago
film42•2d ago
rapind•2d ago
gitaarik•2d ago
t_mahmood•2d ago
Now I use vimplug though
porridgeraisin•2d ago
t_mahmood•2d ago
And, also, I was young, and that made me feel good :D
bayesianbot•2d ago
gitaarik•2d ago
bayesianbot•2d ago
recursivecaveat•2d ago
gitaarik•2d ago
ratrocket•2d ago
freedomben•2d ago
behnamoh•2d ago
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•2d ago
the nr of times now people have been owned by rogue plugins via editors is rising each day...
wffurr•2d ago
gitaarik•2d ago
kzrdude•2d ago
OJFord•2d ago
dkdcio•2d ago
gitaarik•2d ago
dboon•2d ago
gitaarik•2d ago
freedomben•2d ago
OJFord•2d ago
(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•2d ago
recursivecaveat•2d ago
tasuki•2d ago
I update my plugins when I want/need to.
freedomben•2d ago
vasac•2d ago
tasuki•1d ago
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•1d ago
Piraty•2d ago
rapind•2d ago
root_axis•2d ago
leephillips•2d ago
0x457•2d ago
colordrops•2d ago
0x457•1d ago
schonfinkel•1d ago
Replacing it with nixvim is on my forever growing todo list.
naniwaduni•2d ago
rand0m4r•2d ago
freedomben•2d ago
sbinnee•2d ago
ComputerGuru•2d ago
lawn•2d ago
bravetraveler•2d ago
In the exceedingly-rare event I do want to add one... overwhelmed with choice. "Have to" is entirely self-imposed
Aissen•2d ago
- 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•2d ago
burnt-resistor•2d ago
azemetre•2d ago
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•2d ago
That's handy!
azemetre•2d ago
theflyinghorse•2d ago
amelius•2d ago