Why and how should go_deps expose resolved versions for each Go module it processes?

[Buzz-Lightyear]

I'd like the go_deps module extension to expose the mapping between every Go module it bazelizes and its resolved version. This would be extremely useful for external bookkeeping (for e.g. we can easily communicate to CI systems that rely on native package manager metadata, precisely what version of each Go module was used in the build), not to mention this info would be crucial during security audits.

I started an issue for this: #1905 and a PR to showcase one way of addressing it: #1906

I'd like to start a discussion per @fmeum 's suggestion to gather feedback on the optimal way to do this.

[chenxiao0228]

+1, this is especially useful in an environment where ppl do not have a company wide Go monorepo.

This information is essential to do security audit as well as keeping dependencies fresh, and the module extension has the most accurate data.

@fmeum pls let us know how you think ;) happy to discuss other options too.

[tyler-french]

Can you run a build with https://bazel.build/reference/command-line-reference#flag--experimental_repository_resolved_file

Note that this requires a bazel clean first

[Buzz-Lightyear]

Thanks for chiming in @tyler-french, I gave this a shot and the info is certainly there but the file that's produced isn't a valid JSON. I tried fixing some of the issues but it has one too many. But in theory, this could work if it was actually a valid JSON.

Another minor thing, it isn't in the ideal format. It's a giant list of repos, it would be better if it was indexed on repo name. Any objections to the module extension also producing a resolved dependencies JSON that is being proposed here, to provide this extension specific metadata? The approach is identical to the file that's produced for rules_go's consumption.