RFC: Merge the app repos

[hawkrives]

Today, we have ~2 repos: allaboutolaf, and carls.

I propose that we merge them into one repo, and instead configure Xcode and Gradle to be able to generate the two apps.

This will let us figure out how to structure the common codebase in a monorepo, as we figure out how to make them properly configurable for other projects to use.

It will also prevent us from ever being in the current CARLS situation, where the code was forked 5+ years ago and is very difficult to rebase today…

My proposal has three parts:

The New Repository Structure

frog-pond/allaboutanything

The merged app repositories. Contains the code and configuration for the two apps. However, I think that the data and the images should live in…

carls-app/carls & StoDevX/AAO-React-Native

I think that we should pull the data and images out of the main app repositories, and leave them in separate repos, for a few reasons.

1. It avoids breaking the current apps, because they'll still have the data at the same URLs.
2. It keeps the images files out of the code repo, which is always nice.
3. ???

Additionally, I think that we should stop shipping any images and data files in the app bundle. Instead, I think that they should be fetched on first use. This can be debated both ways, but

1. I like the idea of the smaller bundle size
2. It will make us rethink our data caching, which needs to happen
3. Yes.

Conclusion

I guess I only had one part. Thoughts?

[rye]

Merging the two apps into one repository sounds like a good idea. Or, at least: centralizing them under one set of dependencies, "one" set of configurations — in short, one source of truth for both apps, wherever possible. That sounds like the goal here.

I want to clarify what is being proposed here. Is the suggestion to essentially create a repository, put both apps' code into the repository, and then deduplicate? The question here is: what is being versioned with the shared repository? Do both "apps" get released under the same version counter? (So, e.g., if I make a patch that only affects CARLS, does that also result in a patch release to AAO?) Do I have to check out and test both apps whenever I make a change?

In general, my rule of thumb is that a repository should track some thing. I worry that the ask here is to essentially plop the source code for both apps into the same place, deduplicate as much as possible, and then have scripts that build the two apps separately. This does solve the problem of de-synchronization and multiple source of truth by requiring both apps to be buildable from one source, but the worry I have is that it allows the concerns of the two apps to be muddled, and it just increases maintenance effort. It also allows for potential issues like CARLS code calling AAO code, AAO code calling CARLS code, without the boundaries between the two apps being clearly communicated.

So, I ask, from my Devil's-Advocate standpoint: What about modules? We have a source/modules directory, and I thought the initial idea was to eventually pull those out into their own separately-versioned modules. As an example, let's take BonApp menus, since those are reusable. We'd take all the code that drives menus in both apps, put it into a frog-pond/bonapp-menu package, while also building out necessary test harnesses so that we can construct a menu, plug in all the necessary info and styles, and out comes (1) a button to take us to the menu, (2) the menu view(s), etc. Then, our app is essentially a consumer. All it has to do is call some constructors, fill in info, and out pops the menu.

If we take that kind of encapsulation to the extreme, couldn't we also test a BonApp menu outside of React-Native? Then, if I want to go add a feature, I just need to check out the BonApp part of things, and I could even potentially make those changes without having to fire up a simulator! Taking this to its conclusion, AAO is reduced essentially to a collection of calls to constructors, styles, configuration, and the like, and this could probably be templatized and turned into a turnkey, "fill out this YAML" sort of thing.

Maybe this is the ultimate goal of the monorepo approach, and we would naturally be pulling out shared components and doing this along the way, but I want to make sure that we're not just mashing the two things together and hoping it'll solve all our problems.

[hawkrives]

Good questions, Kris! I will need to ruminate and organize my thoughts.

[hawkrives]

You mention a philosophy of "one repo = one thing." I may need you to elaborate on that, because I think I'm leaning towards a monorepo…

---

I think that this is what I'm thinking:

We currently have two repos, AAO and CARLS. We want to end up with three source trees: AAO, CARLS, and the common library code.

Long term, I don't have much of an opinion of how many repos we should have.

Short term, I think that moving everything into a monorepo allows us to more easily factor out the common code from the current AAO source tree into other modules.

I feel that a monorepo makes it easier to make sweeping changes across both a package and the consumers of that package, which is especially important during the experiment phase as we reorganize things. I would even like to move our other packages (custom tabs, alternate icons, titlecase) into this monorepo.

---

I do like the end goal of a turnkey solution, where we allow creating an app by filling out a config file. I think that the most straightforward way to get there is to merge everything together, so we can see where the common code is.

[drewvolz]

I'm thinking the monorepo idea will be helpful because we are the only consumers of the reusable things we're creating.

Collocating all project owned package forks and separate dependencies that exist for these projects should make for easier refactoring, locating, updating, and reuse processes.

I'd also like to propose the idea of merging the data/caching server into the file structure of this monorepo. ccc being a sibling to aaa could cut down on friction.