Reorganizing bonzAI

I have some codebase architecture questions. If anyone would like to comment, it is appreciated. It can be discussed in #bonzai_public on the screeps slack.

I'd like to clean up bonzAI a little bit. Right now you could separate it into two parts.

1. Its operations/missions architecture which is fairly solid (overview here: https://docs.google.com/drawings/d/1SY29wu58jtTBadaJ6U1CMFu2kqRZfOhbyoSmFyYlfiI/edit?usp=sharing)
2. Empire and all the helper classes and libraries

The part that feels messy is the second part. I have a helper for working with room positions, a helper for working with creeps, etc. Empire is a hub for all the code that is outside of the scope of operations: a map module that represents the game world, a module to handle interacting with the market, etc.

What I'd like to do is have a top level object that acts as a reference holder to all these modules/helpers. Something analagous to the Game object provided by the Screeps API. Then my missions/operations would only need to import that. I started out doing this with empire but I think the problem is that i've only done it half way. I still have a lot of static classes that act as helpers.

As a result, my import list tends to be fairly long for each file. I've tried to keep things decoupled at least as far as it makes sense, but occasionally these modules import each other as well, creating a circular reference loop that is sometimes too difficult for commonJS to find a solution and my build fails.

One solution would be to just assign all these modules/helpers as a reference to my top level object, as I've already started to do. Something like this:

root.empire	-> empire and all its submodules
root.pos 	-> PosHelper
root.matrix	-> MatrixHelper
root.creep	-> CreepHelper
root.traveler 	-> Traveler
etc.

As a result, nearly every file would import my root object, even some of the modules/helpers that get assigned to it. This would certainly clean up my imports and to me it feels like a cleaner way to organize the codebase. I'm not sure sure if commonJS will have an easier time resolving this organization or not, but I suspect it will.

Are there any pitfalls/problems with this method of organization that I'm not aware of? In a way, everything is coupled with the root object. But then again, the actual modules that are assigned to root can be swapped out with different implementations. root merely defines the interface for the codebase. Does this reasoning hold up?