Solving the Stress of Monorepo Management with Bit
Organizing and avoiding a growing tech debt on a fast-growing startup
Let me know if this sounds familiar: you had a team of roughly 3 developers working on your product’s MVP for about 3 months.
The product got market fit, which meant the team had to suddenly grow, fast.
You suddenly went from 3 to 8 developers, 4 of them being back-end devs, 3 of them front-end devs and one Data Scientist to start planning what you’ll do with the data collected by your app.
To make matters worse, you don’t have the time to restructure your original monorepo. Not necessarily a bad thing, but it does make things harder when trying to keep coupling at bay.
The cherry on top? Only some of your team members are versed in Git, which means your monorepo branching strategy is starting to cause trouble, and you’ve had some instances of front-end developers overwriting code from the backend team by accident.
You need speed, but the current technical debt is only going to get worse.
The solution
Your main problem is organizational, you have too many developers with different skill levels working on the same code essentially, and most of them are using tools they don’t know and have the potential to destroy the entire project.
It sounds harsh, but the minute you accept this reality the sooner you’ll start seeing the solution: simplifying the toolchain.
Let’s face it, right now it’s too complex and at the current rate you’re having problems to:
- Properly version your different sections of the code. I’m not just talking about front-end vs back-end, but rather being able to individually select and extract components that can either be distributed individually or even properly turned into reusable components for future projects. Not to mention that this would allow you to assign ownership to different sub-teams, helping organize the current chaos.
- Have a “happy and stress-free” monorepo. You can’t move into a multi-repo scenario, but you can’t keep handling your monorepo the way you are either. You’re pushing your luck every time someone does a merge. It’s only a matter of time before one of those merges ends up creating a corrupted version of your code and you’re forced to spend a couple of days untangling that mess.
Let’s take a look at a tool that can solve all your problems and even give you some interesting abilities for the future stage of your project: Bit.
Extracting components from your monorepo
Yes, I’m proposing that you take your monorepo, grab the parts that you can identify as “components” and get them out.
No, I’m not saying you should break up the monorepo we know you can’t break up.
That’s why I’m suggesting Bit here!
Taken from their website: Bit helps you take complex product requirements, and break them down into independent, and reusable pieces called “components”. It allows you to create components and compose them with each other.
And to my point, Bit allows you to version components that live within your code as if they were part of an external repository. That’s because Bit has its own code repo that you’ll be using.
And the best part? You don’t really have to change that many things in your code to make it work.
You can even organize your components within “scopes” which is what they call their groups. You could have a scope for front-end components, and another one for back-end, or you could even go deeper and have scopes for specific features within your app. Once you have your scopes set up, you can then have different dev teams work on them individually without fear of them colliding with each other.
To learn more about how Bit handles namespacing with scopes:
And the process is as easy as doing:
npx @teambit/bvm install #to install bit on your system
bit init # at the root of your project to get everything going
bit start # to get the UI going, visit http://localhost:3000 nowAt this point, you should be able to browse to http://localhost:3000
Here you’ll see something like this:
That means you still haven’t identified any of your components inside the project, so now let’s do that.
I’m working with a sample To-Do app in React that has 2 components inside the src/components folder. So I’m going to turn both of them into Bit components. And I can do that easily like this:
bit create react ui/todo-list --scope my-org.my-todoapp
bit create react ui/todo-item --scope my-org.my-todoappThat line will create two new component folders inside a folder called my-todoapp/ui/ at the root of my project. I can now move my files there to keep them individually maintained.
I can also change my original files to export the new components using the new symlink created by Bit inside the node_modules folder. That way my files now look like this:
#src/components/ToDoItem.js
export {ToDoItem} from '@my-org/my-todoapp.ui.todo-item'and
#src/components/TodoList.js
export {TodoList } from '@my-org/my-todoapp.ui.todo-list'Note how without me having to do anything, Bit already locally installed these components as modules. And while the server is up and running, whenever make a change in one of these files, the app will be updated as well.
BTW, now the WebUI looks like this:
The documentation was auto-generated so there are still some things to tweak here and there, but all the templates are inside each component’s folder.
Now all I have left to do is to publish my components so other colleagues can use them and work on them as well. I can do that like this:
bit tag # to tag the current version of all components and assign a version number
bit exportNote: To do this, you’ll have to have an account on Bit and log-in from the terminal with the bit login command.
Once this step is ready, my team can access my components and use them/update them themselves.
Notice how I didn’t have to worry about NPM, Git or any other tool. In fact, something I didn’t talk about, is that there is already a test library in place that runs for all your components. You can use your favorite testing library and import your existing tests into the suit.
💡 Bit streamlines this entire process by providing an integrated dev environment (compiler, tester, linter, documentation, CI, dev server, and packaging/dependency management/bundler all-in-one) for building apps with React, via one standardized interface (API, CLI, and UI). It enables you to quickly set up a dev environment that automatically follows best practices. Learn more here.
Solving the stress of the monorepo management
Part of this solution was already shown above.
While I focused on showing you how to get your first component “extracted” from your codebase into a separate folder (still within the same repo) I avoided talking about Git.
And I did that on purpose, you see, one of the benefits of using Bit, is that all the tools from the usual developer workflow are abstracted behind it. I’m not only talking about Git, I’m also talking about the package manager, the testing library, the linter and more.
It all gets “absorbed” into the Bit workflow, and while behind the curtain you’re still using those tools, you’re not directly interacting with them.
So instead of having to create a commit for a new version of a component, you can simply go bit tag 2.0.0 my-scope/my-component and then export it again with bit export . That’s it, there are no need to merge things, to be careful about the commit history or to ensure you created this branch from the correct one.
Bit is a great abstraction to the developer workflow, thus your developers can forget about worrying whether or not they’re properly using the monorepo and instead, they can worry about finishing their tasks.
If you want to know more about how to tackle the organization of a monorepo through Bit, read this detailed tutorial from their documentation.
Conclusion
Overall, the chaos I described at the start of this article is quite common with startups that grow too fast, and there are definitely many ways to solve those problems.
That said, if you’ve never heard of Bit before, or if you’ve never given it enough time to check it out, this might be the best moment to do so. It can be the answer to all your problems!
Have you solved similar problems through Bit? What was your experience like?
From Monolithic to Composable Software with Bit
Bit’s open-source tool helps 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
