What is the monorepo work flow? Every time I update the common components lib, I have to update other place where has it dependency. Is this normal?

Question

Case steps:

1. I have packages/common packages/react-A these 2 sub projects inside packages
2. react-A has a dependency [email protected]
3. I upgraded common from v1.0.0 to v2.0.0, and did a lot of change.
4. The react-A will show errors because it's dependency will update too.

Every time I upgrade my common library for a major change, I have to fix other place where has it dependency, is that normal way?

Answer 1

TL;DR - yes, changing the visible / API code of a common dependency which is shared amongst many will force you to conform to those changes across different projects. This is expected.

---

What is the monorepo work flow?

A monorepo is a version-controlled code repository that holds many projects. While these projects may be related, they are often logically independent and run by different teams.

The workflow includes (but not limited to) things such as:

• Large scale commits - commits that may or may not affect multiple separate projects at the same time.
• Code visibility - projects see code of other projects.
• Shared commit history - commits that affect more than one project shall be visible.

and many more things. Hence, the workflow is to manage multiple projects under a single history tree. How you do that is team specific...

---

I think that there are great online resources and blog posts that describe what a monorepo is in great detail, so I won't go into that, since I don't think this is the essence of the question. Whether you have a monorepo or just one project with a couple of submodules in it, is for you to decide, since a monorepo is more of a concept than an actual physical thing (I'm taking the definition rather lightly here).

But I think that your question is less related to the monorepo workflow and more to do with general software design.

You have a common library. That library may or may not have an API which others will use. That API of that library may or may not change with time. If you are in control of how that API changes, then it's more than obvious that if you change the API, everyone that integrates with that library will have to conform to the new API.

If v1 of common has a set of specific method signatures that dictate how the API is and v2 of common changes these signatures, then users migrating from v1 to v2 must change the way they use common. Fundamentally, it's no different than you refactoring your code internally or just changing functions for your own project. Now, if this approach does not appeal to you and you wish to have backwards compatibility and a stable API, then there are specific software engineering methodologies to ensure such stability and flexibility, but most of all, it's an effort you have to put in, so that implementation changes don't affect you API, which will then affect/not affect your other projects.

Answer 2

There are also great tools like Lerna that can make it much easier to manage the updates to dependencies across related projects.

The Material Web Components repository is a useful example of how this can be done (https://github.com/material-components/material-web), and Lerna provides the option to have each package within the monorepo maintain its own version numbering or to version them all consistently.

So far I prefer the first option given that by SemVer standards a breaking change to one package won't necessarily create a breaking change in another one, because the breaking change in the dependency may have been handled by the dependent package internally.