Break up events package

[lukemassa]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

• I'd be willing to implement this feature (contributing guide)

Describe the user story

As a contributor, it is often difficult to navigate and understand the interdependencies of the events package. Some data confirms it is far and away the largest package in the codebase:

atlantis % for j in $(for i in $(find . -type f -name '*.go'); do dirname $i; done | sort | uniq); do echo -n "$j  "; cloc $j/*.go | grep '^Go' | awk '{print $5}'; done | sort -rnk2 | column -t
./server/events                           25592
./server/events/vcs                       6706
./server/events/mocks                     5674
./server/core/runtime                     4776
./server/core/config/raw                  4658
./server/controllers/events               4048
./server/core/config/valid                2828
./cmd                                     2334
./server/core/config                      2095

Having large packages is unavoidable, but "events" has become just a "kitchen sink", and the fact that it's 4x the next largest package is to me a code smell.

Describe the solution you'd like

I'd like to start pulling logic into subpackages of events, in the spirit of vcs and command. I don't want to do this "just for the sake" so would be looking for semantically related packages that have a comprehensible interface they expose to the rest of the code base.

Describe the drawbacks of your solution

Obviously a large refactor is a risk. Also moving large numbers of critical files around makes git histories difficult. I'm just afraid the problem is only going to get worse as events becomes more and more a center of gravity.

Describe alternatives you've considered

Code could be pulled out a different way, like to a sibling package? But "lowering" into a subpackage seems the more obvious.

[GenPage]

I think this is a useful data point and callout. I also appreciate that you are thinking about the risk of a large refactor and moving files/codes for the sake of moving it. I would like to see more details or a deep dive about the particular functions we want to sub-package to make sure we're purposeful in organizing things better.