Automated Version Alignment for Angular Native Federation Ecosystems

[ng-druid]

For which library do you need help?

native-federation

Question

Hello,

We’re running into a version‑management challenge in a large micro‑frontend ecosystem built with Angular’s native federation. The ecosystem consists of:

• Quell Core – the source of truth https://github.com/rollthecloudinc/quell
• Spearhead distributions – host applications https://github.com/rollthecloudinc/spearhead
• SOLIDs – independent Angular MFEs loaded at runtime as plugins https://github.com/rollthecloudinc/solid

• Example of a solid: https://github.com/rollthecloudinc/solid-quill

All of these depend directly on Quell Core and share the same Angular and library versions. For compatibility, every Core release requires every SOLID and every distribution to be rebuilt using the exact same dependency versions. Today that process is entirely manual.

The Problem

1. When Quell Core is updated, all SOLIDs and distributions must also update their dependency versions to match.
2. SOLIDs need new versioned build folders (immutable per Core version).
3. Distributions need new Git tags.
4. Every build must publish to GitHub Pages or GitHub Packages.
5. Maintaining this manually across many repos is error‑prone and doesn’t scale.

Proposed Solution

Use a GitHub‑native automated release workflow that triggers from Core:

1. A new Quell Core release fires a repository_dispatch to dependent repos.
2. A reusable GitHub Action updates dependency versions, rebuilds each repo, and publishes outputs.
3. SOLIDs publish new versioned build folders (per‑Core immutable).
4. Distributions publish new tagged releases.
5. All shared library versions remain strictly aligned across the ecosystem.

                 ┌─────────────────────┐
                 │     Quell Core      │
                 │  (source of truth)  │
                 └──────────┬──────────┘
                            │
                            │ New Core Release
                            ▼
                ┌──────────────────────────┐
                │ GitHub Action in Core    │
                │ triggers repo_dispatch   │
                └──────────┬──────────────┘
                            │
   ┌────────────────────────┼────────────────────────┐
   │                        │                        │
   ▼                        ▼                        ▼
┌───────────┐        ┌──────────────┐        ┌────────────────┐
│   SOLID    │        │   SOLID      │        │   SOLID        │
│  Plugin A  │        │  Plugin B    │        │  Plugin N       │
└─────┬──────┘        └──────┬───────┘        └───────┬────────┘
      │                      │                       │
      │ Auto‑update deps     │ Auto‑update deps      │ Auto‑update deps
      │ Rebuild              │ Rebuild               │ Rebuild
      ▼                      ▼                       ▼
┌──────────────┐     ┌──────────────┐        ┌──────────────┐
│ Versioned     │     │ Versioned     │        │ Versioned     │
│ Release Folder│     │ Release Folder│        │ Release Folder│
└──────────────┘     └──────────────┘        └──────────────┘


                            (Parallel)

                            ▼
                 ┌────────────────────────┐
                 │ Spearhead Distributions│
                 │  (docs, blog, etc.)    │
                 └──────────┬─────────────┘
                            │
                            │ Auto‑update deps
                            │ Rebuild
                            ▼
                 ┌────────────────────────┐
                 │  Release Tag per Core  │
                 │  (no folders needed)   │
                 └────────────────────────┘

Flow summary

• Quell Core releases a new version.
• Core triggers dependent repos using GitHub’s repository_dispatch.
• Each SOLID rebuilds into a new versioned folder (immutable per Core version).
• Each distribution rebuilds and publishes a new Git tag.
• Shared dependency versions remain aligned automatically.

Does this sound like anything that has been thought through or built already?

Interested in more of the conversation available here: rollthecloudinc/hedge#381

[ng-druid]

Here’s the landscape:

• Mono‑repo tools like Nx, Turborepo, Bazel, and Lage automate dependency‑based rebuilds — but they only solve the problem inside a single repository, not across many independent repos using GitHub Pages and multiple build artifacts.

• Release managers like Changesets, Lerna, Semantic‑Release, and beachball can version and publish packages — but again, only in one repo, not across a federated architecture where each MFE is its own repo and build target.

• GitHub Actions provides the primitives (workflow_call, repository_dispatch, Pages deployment), but nothing that automatically propagates version bumps, rebuilds MFEs, and publishes versioned artifacts in separate repos.

• Module Federation tooling (Angular Architects, Webpack MF plugins) focuses on runtime integration, not multi‑repo release orchestration.

• Micro‑frontend orchestration platforms (e.g., Open Components, single‑spa, Bit, Piral) provide runtime loading and component registration, but they do not manage dependency alignment or cross‑repo build pipelines.

So although you're using familiar concepts (CI/CD pipelines, module federation, version propagation), the combination of:

• independent repos,
• version locking to a core package,
• GitHub Pages as the delivery mechanism,
• immutable per‑version build folders,
• tag‑based distribution releases, and
• automatic ecosystem‑wide rebuilds

does not exist as an open‑source solution today.

Effectively a multi‑repo, GitHub‑native release manager for federated micro‑frontends — something that doesn’t currently exist but would be broadly useful far beyond our needs.

If built in a generic way, it could genuinely fill a gap in the OSS ecosystem.

[ng-druid]

Without a proper release‑management system, the entire federated architecture becomes fragile. Core, distributions, and every MFE all depend on strict version alignment. Without automation, even a small Core update risks breaking dozens of downstream modules, and everything quickly becomes unmaintainable.

Building this system isn’t optional — it’s foundational. The good news is that what we need is very achievable using GitHub‑native tooling. Once it’s in place:

• Core updates become safe and predictable.
• MFEs stay compatible across all versions.
• Distributions stay synchronized without manual work.
• The whole ecosystem gains long‑term stability.
• And you end up with a generic solution that others in the micro‑frontend world can benefit from.

This system essentially becomes the backbone that allows the entire architecture to scale cleanly.

[Aukevanoost]

I really like your idea and the effort you put into this. However in my opinion, the idea of a federated release platform doesn't exist for a reason.

It seems like you want to build a distributed monorepo. I'd say, if the packages releases are really this coupled to eachother, why not transform it into a monorepo. The idea with all these micro frontend eco-systems and the ideology they share with runtime integration is built upon the idea of decoupling codebases. In other words, we're putting the micro frontends and core libraries in different repositories because we want to deploy, run and maintain these codebases individually without any dependency on the other codebases.

In practice, this means that we manage per codebase which dependency is needed, that could mean that not all codebases have the same Angular version etc, but that doesn't have to be a problem. We're using runtime orchestration to resolve all the dependencies and wire the dependencies to their respective micro frontend, you can check the docs of our runtime orchestrator here: https://github.com/native-federation/orchestrator/blob/main/docs/version-resolver.md

Besides, it doesn't matter if the dependencies aren't updated realtime, at my company we're using a bot like dependabot or renovate to update our dependencies as soon as an update is available. This is only possible with a robust QA pipeline though (testing, linting etc.). We still release manually but frankly, I think that's the way to go to maintain a grip on what's live on production. The whole goal of micro frontend architecture is to allow teams to maintain their codebase isolated from all other codebases, I feel that this idea is counterproductive for that ideology.

Hope this helps :)