Skip to content

Refactor/vim.pack#2005

Draft
oriori1703 wants to merge 5 commits intomasterfrom
refactor/vim.pack
Draft

Refactor/vim.pack#2005
oriori1703 wants to merge 5 commits intomasterfrom
refactor/vim.pack

Conversation

@oriori1703
Copy link
Copy Markdown
Collaborator

@oriori1703 oriori1703 commented Apr 20, 2026

Migrate from lazy.nvim to vim.pack.

Caution

This is still a WIP experiment, and we may decide to stick with lazy.nvim
There is still more work to do and I'm looking for feedback.

Tasks / need feedback:

  • Choose between one big vim.pack.add in the beginning vs vim.pack.add near each relevant require
  • Better doc strings for vim.pack
  • Measure the startuptime diff
  • Maybe add more lazy loading for heavier plugins? Seems like the performance is good enough without it :)
    • If so, should it be using plain autocmds or using mini's MiniMisc.safely()

If you want to make it easier to see the diff, I suggest cloning and running git diff --ignore-all-space --ignore-blank-lines e099979958b110ab20524e67e1f57ddef9eb6cb0 (or the commit id of the first commit, if I rebase this branch)

fixes #1630

@nathanzeng
Copy link
Copy Markdown
Contributor

Great work, I am strongly in favor of using vim.pack

Startup Time Diff
This will differ based on hardware, but I was getting 65-75ms with this branch and 42-47ms with the master branch.
I measured using nvim --startuptime startup.log and looking at the bottom of the log file.

Lazy Loading
I don't think it's necessary, but maybe add a note saying to look into autocommands, MiniMisc, lazy.nvim, etc. if concerned.

@oriori1703
Copy link
Copy Markdown
Collaborator Author

I also did some testing of my own and the results are promising :)

It seems that after adding vim.loader.enable the vim.pack is only 3-4 ms slower than lazy (both of them were measured after a couple of restarts to allow them to compile the bytecode).

lazy.nvim (master 9b4fbc5) vim.pack (18c335c) vim.pack + vim.loader (bcf7a2c)
064.016 094.045 067.264

Relevant system info:

orip@Ori-pc ~/.c/upstream-kickstart (refactor/vim.pack)> inxi
CPU: 8-core AMD Ryzen 7 5800X (-MT MCP-) speed/min/max: 4195/614/5363 MHz
Kernel: 7.0.0-200.nobara.fc43.x86_64 x86_64 Up: 2d 13h 8m
Mem: 9.5/31.25 GiB (30.4%) Storage: 5.48 TiB (12.0% used) Procs: 511
Shell: fish inxi: 3.3.40

orip@Ori-pc ~/.c/upstream-kickstart (refactor/vim.pack)> nvim --version
NVIM v0.12.1
Build type: Release
LuaJIT 2.1.1774638290

orip@Ori-pc ~/.c/upstream-kickstart (refactor/vim.pack)> ghostty --version
Ghostty 1.3.1

Version
  - version: 1.3.1
  - channel: stable
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .gtk
  - font engine   : .fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 7.0.0-200.nobara.fc43.x86_64
  - desktop env   : other
  - GTK version   :
    build         : 4.20.3
    runtime       : 4.20.4
  - libadwaita    : enabled
    build         : 1.8.4
    runtime       : 1.8.5
  - libX11        : enabled
  - libwayland    : enabled

@feketegy
Copy link
Copy Markdown
Contributor

I just converted my own configs to use vim.pack exclusively without any issues; and the startup time is not noticeable at all between vim.pack and lazy.nvim.

Given that the current config uses lazy require at each relevant point in the file, I would favor replicating that with vim.pack. I think it would be clearer for users that all related code are grouped together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Use vim.pack as package manager when Nvim 0.12 is released

3 participants