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 independently run for development (something like storybook, although I don't recommend it)

6) Preferably with the packages being kept small, lean, with limited number of external dependencies (ie, settle on the cross-team deps to use, so framework, routing, data-fetching, etc)

7) Some kind of pre-commit git hook or CI script to validate a set of core shared dependencies used by packages are kept in sync (ie, everyone is running the EXACT SAME React version). I use this one: https://gist.github.com/DanielHoffmann/a456aadb2f27880d59241...

8) Shared build configuration and tools, all apps are validated, built and bundled by the same code.

9) NO PACKAGE PUBLISHING/VERSIONING, all dependencies are workspace:*

For example:

  folder-structure:
  /apps/{team1-app-name}/
  /apps/{team2-app-name}/
  /packages/auth/
  /packages/some-util-lib/

  /package.json
  "scripts": (test, lint, format, typecheck all done at the top level package.json)
  "workspaces": [
    "apps/*",
    "packages/*",
  ],

  /packages/auth/package.json
  "scripts": (dev to run in development mode)
  "devDependencies": { "some-util-lib": "workspace:*", "react": "^18.0.0" }
  "peerDependencies": { "some-util-lib": "*", "react": "*" }

  /apps/{team1-app-name}/package.json
  "scripts": (dev to run in development mode, build for production builds)
  "dependencies": {
     "auth": "workspace:*"
     "some-util-lib": "workspace:*"
  }

This doesn't give you 100% of the independence of microfrontends, but it does give you quite a lot of bang for your buck. Depending how much independence or reuse you want you might want more or less shared external dependencies (for example your shared packages could be framework agnostic and just use raw JS)

The build/bundling configuration can set up separate chunks for the core set of shared dependencies (react, router, etc) to improve build times, load speeds and caching*

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 establish much stronger lines of ownership and responsibility. Obviously we see other compelling reasons to take this big step, but there’s also a lot of risk involved, particularly around dependency management and figuring out how to accomplish eventual UI consistency across our web apps, all of which will use a large number of shared libraries/components that will be broadly organized into a handful of repos (likely monorepos) representing domains and owned by different teams. The intent is for this evolution to culminate in a microfrontends architecture as a way to support collaboration across autonomous teams without the need for built-time coupling.

Fair enough, probably far bigger scale than I am used to. But I wonder why move away from a monorepo? Publishing and versioning common packages is a huge pain in the ass, especially for JS projects where you need transpiling, sourcemaps, etc.

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.