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

[brianhuster]

Nvim just merge a PR that add a built-in plugin manager vim.pack. I think kickstart.nvim should switch to it when Nvim 0.12 is released, because it is built-in

[guru245]

We don't have to use built-in features just because they're built-in -- we chooose what works best. For example, even though Neovim 0.11 introduced built-in auto-completion, we opted for blink.cmp because it offered a better experience.

Thanks for the update about nvim 0.12 introducing vim.pack. However, I suspect vim.pack isn't yet as mature as lazy.nvim. If we are going to adopt vim.pack, it should be because it is clearly better -- not simply because it's built-in.

[laurensdc]

vim.pack seems to do less magic than LazyVim. I think this is in line with the spirit of kickstart, where we want people to learn Neovim and have control and understanding of their config.
This should also be taken into account in weighing this decision.

[brianhuster]

Yes, also I don't think it's nice for beginners to copy this code to their config

local lazypath = vim.fn.stdpath 'data' .. '/lazy/lazy.nvim'
if not (vim.uv or vim.loop).fs_stat(lazypath) then
  local lazyrepo = 'https://github.com/folke/lazy.nvim.git'
  local out = vim.fn.system { 'git', 'clone', '--filter=blob:none', '--branch=stable', lazyrepo, lazypath }
  if vim.v.shell_error ~= 0 then
    error('Error cloning lazy.nvim:\n' .. out)
  end
end

---@type vim.Option
local rtp = vim.opt.rtp
rtp:prepend(lazypath)

[sebastianstudniczek]

What about lazy loading? Won't using vim.pack slow nvim startup cause it will load all plugins?
AFAIK vim.pack in 0.12 is just bare minimum for a package manager

[brianhuster]

You can do lazy loading by setting up autocmd manually.

If kickstart.nvim wants to be small, it can't be too featureful. What I see in the current state of kickstart.nvim is that it is too bloated, many plugins have too complicated configuration in kickstart. Not to say it unnecessarily overrides built-in features , like LSP mappings.

[grous0]

I was using kickstart.nvim as scaffolding but now switched to vim.pack. I agree that kickstarter is too featureful to be a scaffolding.

vim.pack is pretty minimal so it was very easy to learn. I recommend using it not because sticking to built-in stuff (i still use blink.cmp) but because it is easy to understand as a beginner.

[grous0]

I also think lazy loading should be handled by the plugin not package manager but this doesn't mean to not use lazy.nvim

[iton0]

Given the ongoing discussion about bloat and the future direction of kickstart.nvim, I think a great solution would be to create a new, separate repository.

We could fork this repo and create a new project called kickstart-minimal.nvim (or a similar name). This new repo would focus on being a truly barebones starting point, using vim.pack and only the most essential, simple plugins.

This approach would allow kickstart.nvim to continue its evolution as a more feature-rich, opinionated configuration while providing an alternative for users who want to learn Neovim from the ground up with the least amount of "magic" possible.

I'd be happy to help with this effort if others are interested. What do you all think?

[grous0]

Given the ongoing discussion about bloat and the future direction of kickstart.nvim, I think a great solution would be to create a new, separate repository.

We could fork this repo and create a new project called kickstart-minimal.nvim (or a similar name). This new repo would focus on being a truly barebones starting point, using vim.pack and only the most essential, simple plugins.

This approach would allow kickstart.nvim to continue its evolution as a more feature-rich, opinionated configuration while providing an alternative for users who want to learn Neovim from the ground up with the least amount of "magic" possible.

I'd be happy to help with this effort if others are interested. What do you all think?

This is a good idea but i think that it shouldn't be too minimal. Like a new Vim user probably won't like manually compiling tree-sitter parsers and manually installing LSP configs from https://github.com/neovim/nvim-lspconfig

But probably a beginner would like (actually a beginner wouldn't care rather than liking it except when they start tinkering with these) native autocomplete & package manager. Same goes for replacing telescope with mini.pick.

[IFoodstampZ]

You can do lazy loading by setting up autocmd manually.

If kickstart.nvim wants to be small, it can't be too featureful. What I see in the current state of kickstart.nvim is that it is too bloated, many plugins have too complicated configuration in kickstart. Not to say it unnecessarily overrides built-in features , like LSP mappings.

Unrelated; I'm not familiar with the design philosophy of kickstart to an extensive degree, but I think part of the learning experience with kickstart is cutting back on the bloat and breaking it down (and expanding it) to match your use case. Config bloat is neovim, just make a folder with lazy and treesitter in it if that's the level of bloat you are looking for.

[mairs8]

was there any conclusion to this? there seems to be a consensus for vim.pack over lazy.nvim.

[grous0]

was there any conclusion to this? there seems to be a consensus for vim.pack over lazy.nvim.

I will try forking and migrating to vim.pack but this should be done when 0.12 is near release otherwise API changes of vim.pack can be little frustrating because its nightly.

[eamonburns]

Regarding lazy loading in vim.pack: neovim/neovim#35562

[eamonburns]

0.12 has been released! May want to revisit this.

[SetsuikiHyoryu]

I already replaced lazy.nvim with vim.pack in a previous nightly version. I only use 31 plugins and don't really care about lazy loading, so I wasn't too concerned about the differences in that regard. Overall, I'm quite satisfied with the experience, but there is one pain point: vim.pack.update does not change the branch of the plugin directories stored in the Neovim data directory.

Therefore, if a plugin doesn't follow a rolling release model, the update API won't update plugins correctly and doesn't notify you the plugin needs an update.