upvote
Curious why you went back to lazy.nvim? I had to write some stuff to get some kind of lazy loading (now have "immediate", "vim.schedule", and "VimEnter + vim.schedule" lazy modes), plugin specs / setup functions are colocated, and using vim.packs unused `data` for config merging and it works well enough.

Also, your treesitter auto install makes a common mistake: vim file type and treesitter grammar names don't match up. IE a .tsx file has a vim filetype of `typescriptreact` while the treesitter parser is named "tsx". You'll need something like this https://github.com/nvim-lua/kickstart.nvim/blob/cfdc17be3ae1..., and there's still the note that the `vim.treesitter.language.get_lang` call isn't really doing anything, since that function returns whatever is passed in if no parser matching the name has been registered. So that check is moot.

reply
Cool, thank you.

I had some bugs with moving between a laptop and desktop and pack's lockfile kept getting out of sync, and pack didn't handle it well and sometimes even crashed. My build script also sometimes didn't work properly. I just got tired of dealing with it so I went back to lazy.nvim as it just works and does what I need.

reply
Can't argue with that. Since switching to vim.pack I still feel like lazy.nvim loaded faster, but the less my config relies on folke the better (nothing against them personally, I just don't want to go months without bug fixes for all the plugins they maintain)
reply