![]() Given that it is the first time we are taking this action, and our frontend environment is already huge, we decided to give Lerna a try. Looks like a perfect use case for establishing the monorepo.įortunately, there already exist various tools that help with this process and - at least in theory - make repositories migration to a single monorepo a piece of cake. ![]() That quickly arouses the need to introduce an orchestrator that will eliminate the manual work required and speed up the development process by getting rid of the PRs synchronization effort. ![]() While the problem described in the previous section may not sound like a big issue when dealing with just a few repositories, it becomes a huge obstacle when we need to maintain a larger distributed codebase. Ash nazg durbatulûk (one ring to rule them all) Without enough system-wide knowledge about the entire frontend ecosystem, we can easily miss parts of it where the reusable piece of code we have just modified is enabled and, thus, potentially introduce a regression in the module we have not even touched. When we intend to change something that is truly shared, we need to keep in mind that other projects dependent on that part of the software will be affected. Some of the steps also require some manual overhead that involves context (repository) switching that reduces development efficiency even more. The major bottlenecks in the above flowchart representing the current feature development process are indicated by asterisks. Placing multiple JS-based projects and their common dependencies in separate repositories without an automated process that links them together and keeps them up-to-date kills reusability. While we all admit that projects have to be independent in general, it is also natural to agree that in order to follow the DRY principle and reduce the amount of duplicated code, some pieces should be reused. Some of the code we craft, however, should have the ability to be easily plugged into other projects - shared atomic components (to be consistent with styling guidelines), code style plugin configs, or even whole screens that - despite displaying different data - are present in multiple software packages. Projects must be independent and keeping them separate makes their build process easier to customize and avoids tight coupling with a specific set of dependencies that may not necessarily be used by each of them. Even with code splitting and other modern optimization techniques, there is no point in creating one huge monolith. Splitting different business subdomains relying on the same technological stack (JS + React) into separate modules makes perfect sense. We often end up having two or three components doing exactly the same with different implementation under the hood, which means that the area for potential bugs is bigger, and we need to maintain twice/three times as much as we could with proper architecture that raises the awareness about existing modules. Even though we are all trying to keep an eye on everything going on around, it is quite tricky to discover the existing codebase pieces that - after minor adjustments - can be easily reused across multiple projects. The frontend ecosystem in my company grows really fast. Sit back and hear the story about trials and errors, after which I can admit that I have been able to face it. Recently I volunteered in the challenge of migrating multiple full-blown commercial frontend projects into a single repository.
0 Comments
Leave a Reply. |