Back to lazy.nvim

Published: June 25, 2024

Revised: June 25, 2024 in 3cb913c

Around a month ago I had an affair with rocks.nvim. It was fun, but I’m back together with lazy.nvim again. This is a short post to explain why—at this point in time—the grass wasn’t greener on the other side.

Problems with rocks.nvim

Too many weird issues.

I had quite a few weird bugs that I couldn’t pin down. What finally broke the camel’s back was that I couldn’t run neotest with Elixir. I think the problem was that I didn’t have the correct treesitter grammar but no matter how I tried to :Rocks sync, :Rocks update, :TSInstall, or nuke the nvim folders in ~/.local and do a complete reinstall, I couldn’t get it to work.

I don’t want to mess with my Neovim configuration when I’ve got work to do. With lazy.nvim these issues went away.
Update and sync was really slow.

:Rocks update and :Rocks sync is painfully slow compared to lazy.nvim. I was already frustrated with packages breaking and having to wait for the :Rocks sync to finish when I trying to fix them made me want to smash the computer to pieces.

That there’s no way to update or sync an individual package was just gravy.

Update

I’m told that :Rocks install {rock} updates an installed package.

Lazy.nvim 11.0 supports luarocks and rockspec

The single reason I started looking into rocks.nvim was support for luarocks where plugins can specify their own dependencies so that I don’t have to. With 11.0 lazy.nvim added support for luarocks including the ability to specify any luarocks dependency (such as a toml library).

Given that lazy.nvim supports semver versioning and :Lazy restore there are no longer any features I need that rocks.nvim have that lazy.nvim don’t.

I will be faithful, I promise

I really need my configuration to just work and unfortunately that wasn’t the case for me with rocks.nvim. That’s why I’m back to lazy.nvim and I’m really enjoying the fantastic speed of lazy.nvim. Why did I ever leave you?