Introducing an AEP monorepo

[toumorokoshi]

Starting this discussion, based on an meeting sync from @thegagne and I.

There are a few repositories that use Go today:

• https://github.com/aep-dev/aepc
• https://github.com/aep-dev/aepcli
• https://github.com/aep-dev/aep-lib-go
• https://github.com/aep-dev/terraform-provider-aep

And some burgeoning projects:

• https://github.com/thegagne/aep-conformance-test

Many of these are based on aep-lib-go today. The changes often required modifying aep-lib-go, then updating the downstream language.

The aep spec is also lockstep, so any change requires modifying many downstreams to adhere to the new or extended guidance.

There are also shared tool that would be valuable, such as agent skills to evaluate spec conformance of the code.

With this in mind, I'd like to propose a new aep monorepo from which we will fold all of these dependencies into each other.

Wanted to get some initial feelers. The high-level sketch is:

1. using go build to start. If the language because polyglot, adopt bazel.
2. using OWNERS files to help divide ownership.
3. release versions TBD - would love feedback and thoughts on that. But can still be versioned and published independently as needed regardless of it's presence in a monorepo.

If we moved forward, we'd start by:

1. expanding aep-lib-go
2. porting aepc, aepcli, and possibly aep-terraform-provider into the repository.

Would love thoughts and feedback!

[toumorokoshi]

Pulling in questions from slack: (https://cloud-native.slack.com/archives/C04TX46UCTV/p1784922051254259)

What about projects that aren't Go-based, like the OpenAPI linter? If they're not included, is it really a monorepo?

It's covered above, but we can use bazel (bazel.build) to pull it in - I just wanted to start with the go targets first.

1. I'm not confident that I understand what problems moving to a monorepo would solve....

It's covered a little bit, but to reiterate:

• The aep spec is also lockstep, so any change requires modifying many downstreams to adhere to the new or extended guidance. In other words, to make a full change throughout the aep ecosystem today, you have to change the AEPs, then aep-lib-go, then do version bumps in aepcli, aepc, and possibly terraform-aep-provider. So the intertia for a single change is now higher, requiring 5 PRs and 5 reviews. This would bring it down to 2 (aeps + aep-monorepo)..

1. ... and I'm suspicious of the tradeoffs required, like giving up some agility. Plus now your code scanning tools have more to dig through, and even if you're not using some tool you might be on the hook for some CVE (or at least for documenting why it doesn't apply)..

w.r.t. agility I'm curious what agility one loses: I find I'm getting slowed down by the multiple changes I had to make in lockstep and the PR review cycle afterward. Having a single PR would be much easier to manage, as well as enable me to test out a change end to end across an api generator, aep conformance test, cli, and terraform provider.

This also enables an ecosystem of end-to-end testing: we could use aepcli to test interop with aepc, aep-conformance interop with aepc.

Plus now your code scanning tools have more to dig through, and even if you're not using some tool you might be on the hook for some CVE (or at least for documenting why it doesn't apply).

Isn't this the same load regardless? It's either vulnerability scanning in 5 repos, or in a single repository. the net code doesn't change.

[kindermoumoute]

This also enables an ecosystem of end-to-end testing:

This is where I'm sold. There is no reasonable way to maintain end-to-end testing with multiple repositories.

There are a few repositories that use Go today:

• https://github.com/aep-dev/aepc
• https://github.com/aep-dev/aepcli
• https://github.com/aep-dev/aep-lib-go
• https://github.com/aep-dev/terraform-provider-aep

And some burgeoning projects:

• https://github.com/thegagne/aep-conformance-test

Should we add github.com/aep-dev/api-linter to this list?

[mikekistler]

I don't have any strong feelings one way or the other for a mono-repo. If we have resolved that changes should be done in lockstep (not sure that's really necessary, but again I'm not opposed), having a monorepo does seem like it makes that somewhat easier.

[rambleraptor]

Along with being a place for collaboration, GitHub is a place for discoverability.

The big question is: will a single monorepo or many repos make the AEPs more discoverable? One repo has the potential for more stars (?) but multiple show more activity (?). Anybody have opinions on this?