Example Typescript Monorepo Part 3 Reasonings
George Harwood • Jan 30, 2018
This is the third part of a series for setting up a typescript monorepo using typescript, yarn-workspaces, and clean architecture.
You can check out my other posts before jumping in:
*Example Typescript Monorepo - Part 1 - React Native
*Example Typescript Monorepo - Part 2 - API
Let’s do something different, instead of walking through each step of setting up a web workspace and a testing structure, let’s spend some time digesting what is actually going on here and the power of a setup like this.
If you just want to jump into a working setup please feel free to clone or fork my repository.
In the following paragraphs I will be covering the power of a typescript monorepo and an alternative.
Before moving on it might make sense to take a peek at the repository I linked earlier. I’ll be making references to it.
OK, Let’s go.
First, I just want to start by saying this is not a one solution fits all project setup. There are some projects that will never reach or need a structure of this scale, and there will be other projects that I would consider too large.
A good indication that would point you toward a structure like this would be if you are going to be dealing with multiple front end applications, have an api + app setup, and/or need to be able to share code between projects.
This brings me to my first point. A setup like this is powerful. There are a few reasons why I think so, but I just want to touch on the main three.
One. Shareable code at your fingertips.
Not the greatest experience. When you add multiple applications with multiple shared modules, it’s almost like whack-a-mole. Constantly putting out fires with any new feature.
With a monorepo, there is no build, push, pull madness. You want to make a change? Great. Do it and make any other changes you need. There won’t be any release craziness to waste your time.
Two. Global Testing.
It is now all of a sudden possible to watch all unit tests across all your projects and shared modules. And it is instant. So if you make a change in a shared module, all project tests that referenced that module will yell at you, pointing you in the direction you need to go.
Lastly, after some research and tinkering I have only really found one alternative to a similar set up like this. You could try using lerna if you like the idea of your modules still getting published. Their goal is to ease some of the pain around multi module management.
I tried to implement something similar to this using lerna, but found react-native to be unruly. I think it could probably be forced to work, but I wasn’t having it.
Anyways, I hope this blog series has been helpful. If you have any questions or issues feel free to reach out through Github issues.