What is expected to occur to Lazy.nvim after Neovim has a native package manager?

[MMachado05]

I've use Lazy for a quite a while, and I've really enjoyed it thus far. Nonetheless, Neovim is actively working towards creating a natively-supported package manager for plugins, with work ongoing in this issue.

As I understand it, vim.pack works to serve as a blanket replacement for tools like packer, vim-plug, and even lazy. Thus, when this occurs, what is the expected direction of Lazy? Will it continue to exist for those that prefer its paradigm, but maybe use more of vim.pack in the background? Or are there plans to archive the project in favor of users "just using" the native package manager?

[Nicknamely]

bump

[uchoa]

I would say this is not something that needs to be planned so much ahead. Lazy, the package manager, supports LazyVim. At some point, if the effort dedicated to Lazy.nvim stops making sense for LazyVim in favor of the native package manager, it's fair to suppose that LazyVim would migrate to it and Lazy.nvim would naturally retire.

[MarcWeber]

It's more complicated because plugins might depend on LSPs, so LSP installation
tools exist. In the past Vim was able to use perl/ruby even PHP fork was there
! Now sometimes you need additional tools like pnpm, vite whatever. Probably
many still know YCM (cmake and other dependencies). Sometimes Rust, Python,
Ruby, ... depend on C libraries (eg image or for speed or whatever reason. The
problem is well known: https://github.com/code-once/ypm And Emacs and others
went through this (the many package managers .. external internal ...) The
recurring question is should a package manager (also targeting NIX) or for
some packages targeting NIX or native apt get and only compile the missing
pieces OR ... is ... never ending. If you use Rust only the problem is
smaller because most dependencies are Rust (cargo). buck2 / .. others don't
work on all linux systems (yes, could be made work, ..) but no binary dist
like, right, ... So .. The real fix also means fixing the mess of programming
languages like dynamic vs compile vs jitting (when at compile time at runtime)
taichi and lua like blur the lines all along and you easily hit the problem of
wanting to have type level descriptions at runtime. So the only fix is
harmonizing languages to allow paradigms in one language and also have a
package manager. But the you're against the world (future still longer than the
past so its worth it .. but ..). Like Rust + its scripting extensions (and they
also kinda settled on GC based ones .. for simplicity ..) .. Why can't Java
replace /bin/sh ? Its because its missing shell completion ? Etc.

Ok summing up:
If we gravitate towards a reusable spec of plugins (and lazy loading, mappigns,
commands, ..) ? a function to activate plugins lazily maybe dependencies ..
then all package managers could implement it - maybe even outside of neovim
(thinking about nix, apt, brew, ..) like python3-* duplication whatever

Its less about the manager (history has shown no matter what you do users will
create new ones because its fun .. I mean VAM was more powerful than
competitors .. yet READMEs started to get ploated telling 4+ ways how to
install plugins :-)

Get me? We have to settle on a common interface.

like

selection_this_world = {
  aliases = {
    // for dependencies so that you can replace some plugins by patched
    // versions ?
  }
  plugin_dir = function(name)
  end,
  plugins =  {
    {
      name = "name", -- so its loadable by others
      init_lua = [[
        // cause this was a genious move to have configuration here !
        // well done
      ]]
      init_vim = [[
        // for legacy plugins ?
      ]]
      dependencies = [ list of names ? - need a way to overwrite ]
      prio = "from-config" # does this really make sense, or can dependencies be used ? or systemd like before  / after ...
      lazy = "from-config"
      activate_on = {
        // read from a addon-info.json (or yaml like !?) ..
        auto = true
        // or define your own ?
        mappings = "from-config" or { overwrite } 
        commands = "from-config" or { overwrite }
      }
    }
  }
}

Then who implements it does no longer matter that much - that would be starting
point. Like LSP: same interface, but for plugins.

And maybe emacs and others could slowly follow.

Now vscode like ? plugins package.json define mappings.
But what if have a plugins which defines M-1 to M-n where n is an option ? :)
There are exceptions always ..
The basic idea is that "selection for this world' kinda describes how to configure THIS setup resolving ambiguity. Eg sometimes there are multiple ways to install something (like python() using sudo apt .. or micromamba or conda or pip -m env .. or ... Something like this would have to go into this sub universe config which might be different on each machine ? Maybe not perfect it would be a step into the right direction IMHO. So should the package manager be within NeoVim (would exclude brew, chocolately, apt, nix and others) ? Or should it interface with one and only be the neovim version of its UI ? Now you slowly get what I mean by selection for this world .. use apt or brew for C dependencies or any of the 3+ c like package managers etc . I think to be classic and never changing we have to IO monad lift out of the neovim/lua world BUT honor and include it. If you're interested in this future send me a message. Sry for the long post - I just think its important to at least understand a vision which is more stable than neovim BUT including and loving it. Honestly its not ever clear whether it should be allowed or not to have tools install more plugins. Eg think about Krita, Blender, Gimp, Inkscape plugins. Now you understand the scalability of the "selection for this world view" cause the pyright python version and neovim (LSP) eventually should work together :)

[kinthaiofficial]

The question of lazy.nvim's future with a native Neovim package manager is worth thinking through carefully — they solve overlapping but not identical problems.

What Neovim's native package manager (vim.pack) provides:

• Plugin installation from git sources
• Basic load-order management
• No external dependencies (built into Neovim)

What lazy.nvim adds beyond basic packaging:

• Conditional loading (lazy-loading by filetype, command, key, event)
• Performance tracking (startup time breakdown per plugin)
• Lock file for reproducible plugin versions
• Profile mode to debug slow-loading configs
• Dependency graph visualization
• Dev mode for local plugin development with symlinks

Even if Neovim ships a native package manager, the lazy-loading infrastructure and the UI/UX of lazy.nvim represent significant ergonomic improvements that would take years to replicate natively.

Historical precedent: npm didn't kill yarn/pnpm — alternative package managers continue to exist when they offer meaningfully different tradeoffs. The same will likely be true here: native packaging for simplicity, lazy.nvim for power users who care about startup time or want advanced features.

The practical timeline: Neovim moves slowly on user-facing features. Even if vim.pack stabilizes in 0.11/0.12, it'll take years before it matches lazy.nvim's feature set. The migration question is probably "when you start a new config from scratch" rather than "now."

For AI-assisted plugin development (an increasingly common workflow), lazy.nvim's dev mode + hot-reload is particularly useful — you can iterate on a local plugin without leaving Neovim.

[WieeRd]

ok chatgpt