Originally assigned to: @rockerBOO, @Penaz91, @DrKJeff16 on GitHub.
Hi maintainers!
I've recently built a project and wanted to ask if you think it would be a good fit for the Plugin Manager section of this awesome list before I go ahead and open a Pull Request.
While lazy.nvim is the undisputed standard today, some minimalists and purists still prefer sticking to Neovim's native pack/*/opt architecture. However, native vim.pack lacks out-of-the-box lazy-loading.
If you use vim.pack.add() during startup, Neovim synchronously sources all plugin/**/*.lua files in the runtimepath, which heavily blocks the UI and ruins startup time (often 100ms+).
The Solution
nvim.pack is a declarative, event-driven lazy-loading engine built purely on native vim.pack.
It uses a load = function() end bypass hack to keep the runtimepath completely clean during the init.lua phase (avoiding the synchronous sourcing trap). It then acts as a JIT injector, dynamically executing :packadd and loading plugin configurations only when triggered by:
Neovim Events (e.g., UIEnter, BufReadPre)
Keymaps (Registers dummy keymaps, deletes them on press, loads the plugin, and replays the keystrokes via nvim_feedkeys)
Deferred timers
With this engine, a heavy configuration with ~50 plugins can achieve a UI-ready startup time of < 50ms, relying on zero third-party package management dependencies.
I know the plugin manager space is quite saturated, but I thought this native approach might be interesting for the community. Please let me know if this aligns with the scope of awesome-neovim. If you think it's a good addition, I'd be more than happy to submit a PR!
Thanks for your time and for maintaining this amazing list!
Originally created by @plutowang on GitHub (Apr 16, 2026).
Original GitHub issue: https://github.com/rockerBOO/awesome-neovim/issues/2276
Originally assigned to: @rockerBOO, @Penaz91, @DrKJeff16 on GitHub.
Hi maintainers!
I've recently built a project and wanted to ask if you think it would be a good fit for the **Plugin Manager** section of this awesome list before I go ahead and open a Pull Request.
### Project: [plutowang/nvim.pack](https://github.com/plutowang/nvim.pack)
### The Problem it Solves
While `lazy.nvim` is the undisputed standard today, some minimalists and purists still prefer sticking to Neovim's native `pack/*/opt` architecture. However, native `vim.pack` lacks out-of-the-box lazy-loading.
If you use `vim.pack.add()` during startup, Neovim synchronously sources all `plugin/**/*.lua` files in the `runtimepath`, which heavily blocks the UI and ruins startup time (often 100ms+).
### The Solution
`nvim.pack` is a declarative, event-driven lazy-loading engine built **purely on native `vim.pack`**.
It uses a `load = function() end` bypass hack to keep the `runtimepath` completely clean during the `init.lua` phase (avoiding the synchronous sourcing trap). It then acts as a JIT injector, dynamically executing `:packadd` and loading plugin configurations only when triggered by:
- **Neovim Events** (e.g., `UIEnter`, `BufReadPre`)
- **Keymaps** (Registers dummy keymaps, deletes them on press, loads the plugin, and replays the keystrokes via `nvim_feedkeys`)
- **Deferred timers**
With this engine, a heavy configuration with ~50 plugins can achieve a UI-ready startup time of **< 50ms**, relying on zero third-party package management dependencies.
---
I know the plugin manager space is quite saturated, but I thought this native approach might be interesting for the community. Please let me know if this aligns with the scope of `awesome-neovim`. If you think it's a good addition, I'd be more than happy to submit a PR!
Thanks for your time and for maintaining this amazing list!
At a first glance, this seems to do a bit more than being a plugin manager, since it includes some plugins itself. So it may be more akin to a "preconfigured configuration".
If it were only an overlay over :packadd and its APIs, it would fit "Plugin Manager" without issue.
<!-- gh-comment-id:4267079701 -->
@Penaz91 commented on GitHub (Apr 17, 2026):
At a first glance, this seems to do a bit more than being a plugin manager, since it includes some plugins itself. So it may be more akin to a "preconfigured configuration".
If it were only an overlay over `:packadd` and its APIs, it would fit "Plugin Manager" without issue.
At a first glance, this seems to do a bit more than being a plugin manager, since it includes some plugins itself. So it may be more akin to a "preconfigured configuration".
If it were only an overlay over :packadd and its APIs, it would fit "Plugin Manager" without issue.
Thanks for the keen eye! You are absolutely right—it started as an experiment to build a pure :packadd engine, but it currently bundles all my personal plugin specs, UI choices, and keymaps.
It definitely fits much better under the "Preconfigured Configuration" category rather than a standalone plugin manager.
I will update the PR to target that section instead this weekend. Thanks for your suggestion!
<!-- gh-comment-id:4267751195 -->
@plutowang commented on GitHub (Apr 17, 2026):
> At a first glance, this seems to do a bit more than being a plugin manager, since it includes some plugins itself. So it may be more akin to a "preconfigured configuration".
>
> If it were only an overlay over :packadd and its APIs, it would fit "Plugin Manager" without issue.
Thanks for the keen eye! You are absolutely right—it started as an experiment to build a pure `:packadd` engine, but it currently bundles all my personal plugin specs, UI choices, and keymaps.
It definitely fits much better under the **"Preconfigured Configuration"** category rather than a standalone plugin manager.
I will update the PR to target that section instead this weekend. Thanks for your suggestion!
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @plutowang on GitHub (Apr 16, 2026).
Original GitHub issue: https://github.com/rockerBOO/awesome-neovim/issues/2276
Originally assigned to: @rockerBOO, @Penaz91, @DrKJeff16 on GitHub.
Hi maintainers!
I've recently built a project and wanted to ask if you think it would be a good fit for the Plugin Manager section of this awesome list before I go ahead and open a Pull Request.
Project: plutowang/nvim.pack
The Problem it Solves
While
lazy.nvimis the undisputed standard today, some minimalists and purists still prefer sticking to Neovim's nativepack/*/optarchitecture. However, nativevim.packlacks out-of-the-box lazy-loading.If you use
vim.pack.add()during startup, Neovim synchronously sources allplugin/**/*.luafiles in theruntimepath, which heavily blocks the UI and ruins startup time (often 100ms+).The Solution
nvim.packis a declarative, event-driven lazy-loading engine built purely on nativevim.pack.It uses a
load = function() endbypass hack to keep theruntimepathcompletely clean during theinit.luaphase (avoiding the synchronous sourcing trap). It then acts as a JIT injector, dynamically executing:packaddand loading plugin configurations only when triggered by:UIEnter,BufReadPre)nvim_feedkeys)With this engine, a heavy configuration with ~50 plugins can achieve a UI-ready startup time of < 50ms, relying on zero third-party package management dependencies.
I know the plugin manager space is quite saturated, but I thought this native approach might be interesting for the community. Please let me know if this aligns with the scope of
awesome-neovim. If you think it's a good addition, I'd be more than happy to submit a PR!Thanks for your time and for maintaining this amazing list!
@Penaz91 commented on GitHub (Apr 17, 2026):
At a first glance, this seems to do a bit more than being a plugin manager, since it includes some plugins itself. So it may be more akin to a "preconfigured configuration".
If it were only an overlay over
:packaddand its APIs, it would fit "Plugin Manager" without issue.@plutowang commented on GitHub (Apr 17, 2026):
Thanks for the keen eye! You are absolutely right—it started as an experiment to build a pure
:packaddengine, but it currently bundles all my personal plugin specs, UI choices, and keymaps.It definitely fits much better under the "Preconfigured Configuration" category rather than a standalone plugin manager.
I will update the PR to target that section instead this weekend. Thanks for your suggestion!