Table of Contents

TL;DR: Lazy.nvim is amazing. It is easy to switch and reduce your startup time immensely. Just try it!

I think Packer.nvim has been a revolutionary plugin manager after nvim 0.5. It introduces a lot of lazy loading techniques to speed up the startup process of Neovim.

Background and history
#

I migrated from vim-plug to Packer.nvim in July 2021 and haven been happily using it since. The advanced lazy-loading reduced my startup time to around 250ms.

However, packer does have its own issues:

It introduces the packer_compiled.lua file. Each time you made changes to packer config, you need to run Packer Compile or Packer Sync to sync your changes. This is error-prone and not user-friendly, especially for novice users.
The Lazy loading mechanisms provided by Packer is somewhat complicated. There are settings such as cond, cmd, key, ft to control the plugin lazy loading.

At the beginning of this year (2023), the renowned plugin author folke introduced Lazy.nvim¹, which quickly gained the attention of Neovim users and has been widely adopted.

Since this year, packer hasn’t been actively maintained anymore, presumably due to the introduce of Lazy.nvim. Not too long ago, Packer has officially announced that it is no longer maintained. This is the last straw that prompts me to try Lazy.nvim.

Migrating from Packer to Lazy.nvim
#

In Lazy.nvim, each plugin has a plugin spec, which specifies how you want to install the plugin and other conditions.

Simple changes
#

The documentation of Lazy has a section on migrating from Packer.nvim: https://github.com/folke/lazy.nvim#packernvim. It mainly deals with some key changes for the Lazy plugin spec.

Lazy-loading events
#

Lazy.nvim provides a special autocmd event called VeryLazy. Basically, you can use VeryLazy for all plugins that do not require immediate use after Nvim startup. However, for some plugins, setting the Lazy loading events to VeryLazy leads to issues. After nvim startup, these plugins do not work properly for me:

andymass/vim-matchup: We need to use BufRead as the event.
akinsho/bufferline.nvim: If we use VeryLazy for bufferline.nvim, the tabline can not be shown. I have to use BufEnter event as the trigger.
nvim-cmp and nvim-lspconfig: The lsp can not be attached to the current buffer if we use VeryLazy. As a result, nvim-cmp can not auto-complete using the nvim-lsp source. I changed the event to { 'BufRead', 'BufNewFile' }, and it works.

Conditional installation
#

Previously when I use Packer, if I want to install a plugin based on some condition, I need to wrap the use{} statement inside the install condition:

if vim.g.is_mac then
    use { "nvim-treesitter/nvim-treesitter", ... }
end

For Lazy.nvim, we can use the enabled key from the plugin spec to control the installation condition, some thing like this:

-- only install nvim-tree on macOS
{
    "nvim-treesitter/nvim-treesitter",
    enabled = function()
      if vim.g.is_mac then
        return true
      end
      return false
    end,
    ...
  },

Multi-level dependencies?
#

If plugin A depends on plugin B (A needs to be loaded after B, since A needs some functions from B), and plugin B depends on plugin C. In Packer, you would write something like this:

use { 'A', after = 'B' }
use { 'B', after = 'C' }
use { 'C' }

In Lazy.nvim, I am not sure how to express this?

{
  'B',
   dependencies = { 'A' }
},
{
  'C',
   dependencies = { 'B' }
},

{ 'A' }

Not sure if this is the correct way to do this in Lazy.nvim?

Lazy vs Packer
#

After switching to Lazy.nvim, even without excessive optimization, my startup time has been decreased to around 40-70ms. Compared to previous startup time of 250ms by Packer.nvim, lazy.nvim is truly amazing.

Lazy.nvim also has a beautiful and feature-rich UI compared to the more primitive Packer UI. You can install, update, sync, profile plugins startup time with ease.

For anymore interested, you can check my current Lazy.nvim config here.