Neovim Pack

Churn in Vim/Neovim package managers & desire for stability

• Many users report a long history of hopping between managers (pathogen → Vundle → vim-plug → packer → lazy.nvim) every few years.
• Several say their current manager “still works” and they’d rather not migrate again; some explicitly blame FOMO for feeling the need to switch.
• Others stick to git submodules or hand-written scripts, valuing predictability and easy rollback over features.

Motivation and role of vim.pack

• Built-in manager is framed as improving “getting started” UX: no need to research third-party managers just to install LSP/treesitter/etc.
• Core argument: Neovim can finally say “put vim.pack.add(...) in config and restart” as a complete answer.
• Maintainers claim it’s small, opt‑in, and helps avoid “shipping the universe” by letting more things be runtime dependencies rather than bundled.

Comparisons to lazy.nvim and other managers

• Fans of lazy.nvim highlight: powerful lazy loading, version pinning/lock behavior, dependency handling, and rich triggers for loading.
• vim.pack is seen as “primitive but promising”: missing first‑class lazy loading and some advanced features, though basic pinning via commit hash exists.
• Some report vim.pack + manual deferring achieves sub‑100ms startup, faster than their lazy.nvim setups, and like removing a “core” third‑party dependency.
• Skeptics argue this duplicates existing high‑quality managers and introduces bloat, especially without automatic dependency management or lockfiles.

Updating plugins & security/supply-chain concerns

• Many simply run git pull rarely or never; if everything works, they don’t update. Others update routinely like any system package.
• Several worry that blindly pulling latest commits (as many managers do) is risky: any plugin has full user-level capabilities (file access, subprocesses, network).
• Practices mentioned: pinning by commit SHA, using submodules, inspecting diffs/logs, or updating infrequently so others hit bugs first.

Lazy loading & plugin design patterns

• Debate over whether lazy loading should be the plugin manager’s job or the plugin author’s via proper initialization patterns.
• Neovim maintainers discourage cargo‑cult setup() APIs and global side-effects; they advocate documented best practices (e.g., nvim‑neorocks guidelines).
• Some argue complex dependency graphs (plugin A depending on plugin B) still require a manager with a clear dependency graph.

Broader ecosystem & alternatives

• vim.pack fits into a broader Neovim push: built‑in LSP, treesitter integration, better OOTB experience.
• Some users prefer Nix/Nixvim, or minimalist configs with few plugins; others mention Helix or Emacs as alternatives with strong defaults and built‑in package systems.