Something I am dealing with at work right now is the idea of pulling all the main structs of our packages into a single package to alleviate(not get rid of) cyclical import issue.<p>The issue I have with this is that when we pull all of the main structs from there packages you disconnect the logic from data structs that us it. Plus remove certain core functionality like more advance logic that would go into a method that cant be simple getters and setters in that struct package.<p>The other issue I contend with is that in doing so it just doesn't "feel" like idiomatic Go. For the many years I have been using Go both core package and open source ones(big and small) and I just don't see many cases where packages completely pull their main structs out. I also try to think about what more advanced developers would do like Rob Pike(https://www.youtube.com/watch?v=PAAkCSZUG1c&t=568s), Brad Fitzpatrick, Russ Cox, I assume they wouldn't think this is a good idea. Presenting various example and quotes from core Go developers didn't seem to sway them.<p>Does anyone have experience in this area? Has anyone pulled their main structs out and have been better off for it? Has anyone pulled them out and then realized it was bad and moved them all back?<p>What are your thought?
This is a horrible idea that will eventually make the situation of cyclical dependencies even worse.<p>Hitting cyclical dependencies is an indication that the code base is not being built in a composable fashion with layers depending on other layers. This is usually solved with more packages of more focused independent functionality rather than less packages of less functionality.
It might be worth hiring an experienced Go developer, even as an independent contractor, to review your codebase as well as to help you lint your code.