[Discussion]: remove packer.nvim from the core plugins

[kylo252]

Description

I've lost count to how many issues are there because packer failed to load/compile/clone a plugin. And since LunarVim is lazy-loading some of the plugins, that means there's a hard dependency on packer starting correctly, or you would end up with a nearly unusable editor.

So let's try to break it down!

Pros

🟢 familiarity with how packer works
🟢 a lot of options for lazy-loading

Cons

🔴 packer can completely break lvim
🔴 effort involved in managing or importing a replacement for it
🔴 core plugins are static: in theory don't require hand-holding
🔴 user plugins have to be managed by lvim: any error in loading user plugins will likely results in breaking packer and so lvim in the process.

[ahmedkhalf]

I fully agree with you, although it will be very difficult especially concerning the lazy loading part. While I am not sure which way we will end up going if we are not using packer, creating our own version of packer would mean reinventing the wheel, which is time-consuming.

I would also like to suggest that if lvim successfully implements a cli as in #1397, we could possibly make package updates and installation outside of vim itself.

[Tastyep]

The more I use Packer, the more I dislike it.
I would not care about losing lazy loading, IMO it's just the cherry on top of the cake, sweet, but meaningless if the cake is missing.
Additionally to all the points you listed, which I agree with, I would add:

• "after" doesn't work, which is a HUGE problem IMO
• "string.dump" makes it impossible to pass scoped variables to the plugin's handlers, everything has to be hardcoded.

Now, the solution is not simple. We don't have the manpower to develop our own solution (we already struggle on lvim).
We will probably end up waiting for wbthomason/packer.nvim#402

[kylo252]

The more I use Packer, the more I dislike it.
I would not care about losing lazy loading, IMO it's just the cherry on top of the cake, sweet, but meaningless if the cake is missing. Additionally to all the points you listed, which I agree with, I would add:

I was getting frustrated with the startup test because I could not find a reliable way to communicate with Packer. So I figured I'll just take a look at how they they verify the lazy-loading in their tests. Well,... I wasn't able to find any test that does anything related to that. And I haven't spent nearly enough time trying to understand how the compliation works, so that doesn't help either.

So now we're in a spot where I'm not really sure how to verify that anything, beyond the basics, work at startup. See: wbthomason/packer.nvim#502