Earlier quoted context omitted.
This gets you most of the advantages of a microfrontend: 1) Monorepo with multiple workspaces 2) With several separate independently deployed applications, each maintained by a separate team 3) That share a set of common packages for common stuff (auth, etc) with full typescript definitions 4) Add CI to typecheck if any shared package changes types you get errors 5) Preferably with the packages being able to be indep…
First off, I appreciate the thoughtful write-up, under different circumstances this is the direction I’d probably be heading. However our web Frontend code is all currently in a large-ish (500 packages, 100 apps) monorepo and we’re actively pursuing breaking that up into a hybrid repo model, largely in the interest of true team autonomy. We want our code organization to better reflect our Eng org structure and to est…
Some smart branch management so teams can work independently seems better for me. For example each project gets their own production branch and development branches to trigger deployments and can pull changes from master as they see fit.
If you are planning on these shared components and dependencies be versioned I highly advise against that, the permutation of versions of underlying common libraries (like React) can make an incompatible versioning hell where component X works on React ^16.0.0 but in practice was tested in React ^18.0.0 only. In my own project I explicitly force all shared dependencies (which I try to keep to a minimum) to be on the same version.
> without the need for built-time coupling
There are two ways of having build-time coupling:
1) Shared build/bundling code, configuration and tools
2) Single build/bundling for all the code
You can most definitely have independent projects sharing the same build/bundling code, configuration and tools while every project is built separately and independently. This can make it hard to integrate with solutions that rely on taking over your bundling though.