go monorepo tooling for package dependencies

[BigLep]

TODO: a go engineer needs to fill this in (@Jorropo? @aschmahmann)

As we have more go monorepos with various packages, we want to have a mechanism (CI check?) for being notified if the dependency closure of a given package expands, especially from taking on a dependency of another package in the repo.

Examples where this has been discussed or where I would believe it would helpful:

• Boxo: this was discussed way back in 2021 when that effort was first being discussed: Consolidate IPFS Repositories ipfs/kubo#8543 (comment)
• Kubo: for example, the Kubo RPC client has been moved into Kubo now. We want to have someone depend on kubo/client/rpc and not pick up other Kubo dependencies. Discussion about this in Lotus: chore: migrate to boxo filecoin-project/lotus#10921 (comment)
• go-libp2p: I haven't heard this be called out, but I assume is relevant given their move to a monorepo.
• lotus: anecodally have heard pain around dependency that gets hit around FFI across the packages.

[galargh]

being notified if the dependency closure of a given package expands, especially from taking on a dependency of another package in the repo

Would you mind rewording this or describing an example scenario when we could use a notification? I want to make sure I understand the idea behind this.

[BigLep]

@galargh

being notified if the dependency closure of a given package expands, especially from taking on a dependency of another package in the repo

Would you mind rewording this or describing an example scenario when we could use a notification? I want to make sure I understand the idea behind this.

Sorry not to be more clear. I don't have a full vision here but taking boxo modules for example, we would want to have a way to say that "gateway" doesn't depend on "bitswap" (and vice versa). If that should ever happen, the build should fail.

It could also be helpful to show the dependency closure from each module in isolation. For example if everyone thinks "util" should be self-contained, but at release time we could check to see if that is still true or check in the dependency tree so so someone can compare between two releases. We would want to validate that any diff is intentional and expected.