From packer to lazy.nvim

I ported my vim configuration again.

This time I swapped out the plugin manager from packer to lazy.nvim. I'm certainly wary of spending too much time on productivity fine-tuning, but since this took a few hours in total and it's been well over a year since the last refactor, I'm okay with it.

porting my longstanding vimscript configuration to lua

Plugin management modularization

In my opinion, the biggest improvement of neovim over vim is to the plugin API. Introducing lua, and providing solid lua APIs to the native treesitter and LSP capabilities has completely changed what's possible for plugin authors. And the predictable result of that change is that modern neovim tends towards a base system with plugins providing more and more central functionality.

So even though I broke apart my configuration into separate lua modules with the vimscript->lua transition, lately the vast majority of the configuration lived in the single lua file that was managing packer and my plugins. Lazy.nvim includes some utility functions to merge lua tables (which act as the language's arrays and hash maps) together, and builds on that to support breaking apart your plugin configuration into separate modules to be merged by the system.

You have a good deal of flexibility with how you can choose to go about this. One file per plugin is certainly possible, but I've opted to use files/modules for logical topics. So, for example, the configuration of all LSP-related modules lives together. There's another for color themes, and another for treesitter, etc. Some of these files contain only one plugin, but they don't have to.

This is the largest practical benefit of this refactor.

Nvim-native UI

The initial impetus for selecting lazy.nvim was actually this: I have been blown away by mason.nvim's UI for managing LSP servers, and lazy.nvim offers something very similar for plugins. I really hope to see more copycats of this paradigm (in particular I'd love to see one for treesitter integrations).

Portable neovim configuration

Mason and lazy.nvim also have this in common: they place the actual assets they manage in ~/.local/share/nvim. What's really important here is that it's not anywhere in ~/.config/nvim, so that directory is entirely hand-written configuration. All this means that (a) the plugins themselves and any support binaries will live elsewhere, and (b) that "elsewhere" can be entirely re-created from the configs using lazy and mason. So what I can do now (and have recently done) on remote machines I manage is:

First completely clear any neovim configuration and assets on the remote machine, then recursively copy up my whole configuration directory. It'll be a small copy because it's just my hand-written lua files (no fzf binary or plugin git repos). The next time I load up neovim on that remote machine, it'll bootstrap lazy.nvim, download all the plugins, and initialize everything.

What's missing

All in all, the new setup on lazy.nvim is superior to what I had with packer in every way. So when I think of something I'd love to see in the future, don't read that as something I miss from the old setup :P

Mason is managing a limited set of LSP options so everything is right there - what you've installed and what you haven't. Lazy.nvim is different because the set of vim plugins you haven't installed is pretty much unknowable. However, it is telling that strings like 'pluginname' automatically reference vim.org/scripts, and strings like 'author/name' automatically reference github.com. With that in mind, it would be great if the Lazy UI offered a means of searching vim.org scripts and public github repos. There would probably be github rate limits to contend with, but otherwise it seems like something that should be doable.

Finally, as I mentioned before it would be amazing to have a UI like Mason but which manages treesitter parsers. I wouldn't expect this to come from lazy.nvim, it's just another plugin that should exist.

---

Home