Splitting out zpay32 & lnwire functionality into a Go library

[torkelrogstad]

I have a Go code base where I utilize "libraries" from LND. I.e. I import LND code, and use that in my code. Specifically, I use zpay32 for constructing and decoding LN invoices, and lnwire to represent monetary amounts and interact with certain aspects of said LN invoices. This is great, and I'm thankful that I'm able to re-use code from LND.

There's one major drawback to this: I end up with an absolutely enormous module graph, because I pull in the entire LND module graph... This has numerous times given me great head ache, as I've had issues with LND dependencies breaking my build. See for example #6930.

There's also (potentially?) security implications by pulling in a large module graph. I received an alert from Dependabot, about GHSA-v23v-6jw2-98fq. This was in my module graph because of the LND dependency.

Intuitively, zpay32 and lnwire seem like packages that should be great candidates for being exposed as clean, dependency-minimised modules available for outside consumption! I'm sure there's plenty of other Go builders that would also be able to use this. Is this something that has been considered?

My code base is unfortunately closed source, so not possible to share here

[torkelrogstad]

I made a PoC for this here: https://github.com/barebitcoin/zpay32

[guggero]

I don't think we need to extract these libraries into their own repository. If we turn them into a Gomodule (by adding a go.mod/go.sum) file each, they behave the same way as if they were their own repositories.
The downside is that any change on that code then requires two PRs: One to the module itself and then one bumping the version in the main/root go.mod after a new tag was pushed.
But since the two packages aren't touched that often and are indeed used on many other projects, I think it makes sense.

Should we turn this into a feature request issue?

[torkelrogstad]

I agree that they shouldn't be their own repositories! The PoC I posted was just for simplicity's sake.

I believe through using Go workspaces, you can get around the need to bump go.mod versions?