Why are we vendoring?

[AndrewSav]

I'm curious, with the go modules now out there for a few years, why are we still vendoring? If it was discussed before, which I'm sure it was please feel free to point me at prior discussions. Thanks!

[jesseduffield]

This probably deserves a justification in the contributing guide. There are several reasons we vendor:

• it allows jumping back and forth between branches that use different dependency versions without needing to re-install the modules
• it allows us to see exactly what is changing as a result of bumping a dependency version (both logic and amount of code)
• we often need to make changes to our underlying library gocui as part of a change to lazygit. It is very easy to make changes directly within the vendor directory and then move the changes across to gocui itself than to make the changes to gocui separately and hook the two up. Again, it's good to have this all attached to the one branch so you can easily commit your changes, switch branches, come back later, and everything still works without any extra steps.
• it's easy to search within the vendor directory for say an error message or a function definition, much more so than if all the vendor code lives somewhere else.

My understanding of the cons of vendoring are that it increases the size of the repo, and that just doesn't bother me that much.

I haven't spent much time (any time really) working with Go that isn't vendored, so if it turns out that the above points are actually weak because of tooling around modules, I'm open to ditching vendoring. But I suspect the pros of vendoring outweigh the cons. I have seen online some strange disparagement about vendoring from the Go team and I have no idea where that comes from.