Code Modularisation Strategy

[gavinhenderson]

It's come up a few times that we want to split the code up but we don't want to end up with a million different repos and having to manage them all.

Here are a few things we might want to split up a bit more:

• Zooming
• Settings UI for web
• Electron build
• IOS build
• Prediction engine integration
• More?

Thats just a vague list, the list will probably grow.

Below I have outlined a few options we could go for. Let me know what you think of the options and what you suggest we go for or if I have missed any.

Git Submodules

We could continue to use Git Submodules. We already use submodules in the electron build.

Personally I am really not a fan of submodules at all. I find they lead to confusion and lots of tooling doesn't play well with submodules.

While they do allow versioning they don't make it very clear, relying on hashes rather than version numbers which are human readable.

There are tools to make submodules better but it feels like a weird hack to make them work.

Monorepo

We can put all the code in one repository.

One nice thing about this is that if we make a change to one module all the dependants will automatically use the new code. This is a bit of a double edged sword though.

It also makes development slightly more convenient having all the code in one repo.

With a monorepo you do have to be strict about your file structure otherwise it gets messy but its possible.

Packages

We can put every 'module' into its own repository. Then we can add automation to publish each module as a package after every commit. The dependant repositories can then use that dependancy.

That way it nicely breaks up the reliance of our modules on one another. We can make breaking changes in one repository without immediately having to worry about its effect downstream as we can update that in our own time.

This approach also works no matter what tech we are using because you can release everything as a package on a registry.

Also note that Github has its own package registry

Combination of the above

We could always do a mix of these options?

[willwade]

I feel I'm leaning on the Packages approach. That seems sensible. Particularly if others use the packages..

[gavinhenderson]

Closing this, as we should do this via the new RFC system