!! Post motivation

Mono repository keyword is buzzing around. As usual, using the newest framework or workflow is not always the best choice. Figuring out, when to use is the real problem.

So let’s check, when the motivation has to be there to gain advantages of a mono repo.

Practise

Before: 3 Repos (2 apps, 1 lib)

Now: 1 Repo (2 apps, >10 libs)

I had a lot of fun doing it, it is a blast overall. In our project, where we managed two apps, which have the same design pattern and use the same business objectives and only differentiate in the workflow.

So the work days were to rewrite existing applications, split it into desired lib size, enhance the unit test code coverage with Jest and unit test with Cypress.

The importance to notice is, we knew the use case of the development, deployment, environment and the use case of the user.

The Good

It worked quite well, I will not go into details, the hard facts are the following:

• We reduced the code base.
• We enhanced our workflow.
• We reduced deployment time.
• No version management in the application, just Docker tags. (Maybe not the best choice, but the lib version is no more.)

Further I realized:

• Cypress is COOL, because the visual experience makes writing e2e tests a lot of fun. It is a delight for the developers.
• Working with libraries should be the norm and working with npm package publishing for internal libraries is a sin.
• Using one repository is the most critical advantage if the fellowship of the code has decided wisely.

The Bad

Creating a new lib or app requires using the nx commands, doing it by hand is too much effort. So I see the danger of too much abstractions.

So on the bad side I realized:

• Losing control of detailed changes of lib/app/test setups.
• Smiliar point, but another direction. Too much generated code, too abstract. In my opinion, it is too much black box business.
• Losing control?
• Jest seems fine, but I had some trouble doing debugging and trying to figure out the real difference between Jasmine. It is faster, that I believe. But anything else?

I would argue, it is mandatory to do the manual integration of a lib by hand before the developers move to the generation commands, which are provided by nx. Take a first good look, a second and please a third look as well, so you really know, what nx is doing.

Think about the future. There might be a time, where the nx introduces breaking changes and you have to work with each framework manually and can not continue with the existing commands.

Future be hold

A good use of mono repos, should as always be decided by the use case and the broad goal of applications in the environment, in which they are development, deployed, used and operated. Further it requires developers to understand the frameworks, which are used, beneath the surface.

I would recommend starting with a single app and doing a migration to a mono repo if a second application comes into discussion.

?? Intrinsic Motivation

So the motivation for a migration should come, if a few of the following points are fulfilled:

• Second or more applications to manage.
• Release cycle, business objects are similiar.
• Apps depend on each other, so released and design need coherence.