DEV Community: Sakthikumaran Navakumar

The Orchestrator - How Native Federation v4 Decides What Loads (and What Changed in 4.8.0)

Sakthikumaran Navakumar — Wed, 21 Oct 2026 02:07:45 +0000

Part 5 of an 8-part series on Native Federation v4 for enterprise architecture teams. New to the series? Start with Part 1: The Mental Model, Revisited.

Part 4 ended with three open questions about the v3 Classic Runtime:

How do you share a library across a range of versions, instead of demanding exact matches?
How do you make singleton and strictVersion actually do something?
How do you avoid fetching everything again on every page load?

The Orchestrator, @softarc/native-federation-orchestrator, is the v4 runtime built to answer them (Orchestrator docs). This article shows how it decides what loads, using the same example as Part 4, so you can compare the results directly. It also covers version 4.8.0, which changed how those decisions are made.

As in Part 4, I ran the Orchestrator's real code (releases 4.7.0 and 4.8.0) against sample files, so every import map below is real output.

How you use it

In Angular, you don't call the Orchestrator directly. The Angular adapter's initFederation() wraps it and sets sensible defaults (adapter source). Your main.ts looks the same as in Part 3.

The big change is what initFederation() gives back. It returns a loadRemoteModule function, which you pass into your app (in Angular, usually through an InjectionToken). In v3, you imported loadRemoteModule globally from the runtime package. That global import still works in v4, but it's marked deprecated.

How it works, in four steps

Fetch every remoteEntry.json, the host's and each remote's, or reuse them from the cache.
Store them in the Orchestrator's caches.
Decide what to share. This is the step the v3 Classic Runtime never had, and it involves two decisions:
- Decision 1: which version of each shared library wins.
- Decision 2 (new in 4.8.0): which build of that package everyone uses.
Write the import map and return loadRemoteModule.

Decision 1: choosing the version

For each shared library, the Orchestrator follows a few simple rules (version resolver):

Only singleton libraries are negotiated. A library with singleton: false gives each remote its own copy, with no discussion.
The host's version wins, if the host uses the library.
If the host doesn't use it, the Orchestrator picks the version that causes the fewest extra downloads. (You can change this to "newest version wins" with the latestSharedExternal setting.)
Then each remote is checked against the winner:
- If the winner fits the remote's requiredVersion, the remote uses it.
- If it doesn't fit and strictVersion: true, the remote gets its own copy.
- If it doesn't fit and strictVersion: false, the remote uses the winner anyway.

So the settings from Part 3 finally matter:

Setting	v3 Classic Runtime	v4 Orchestrator
`singleton`	Ignored	Decides whether a library is negotiated at all
`requiredVersion`	Ignored	Decides whether a remote can use the winning version
`strictVersion`	Ignored	Decides what happens when it can't: own copy (`true`) or use the winner anyway (`false`)
`version`	The only thing checked, and only for an exact match	Used to pick the winner

Same example, different result

Let's take Part 4's example again: the same package.json files and the same remoteEntry.json files. The host has Angular 20.1.4, mfe1 has 20.1.4, mfe2 has 20.1.5, and all three accept ^20.1.0. The host's build includes every Angular part the remotes use (more on why that matters in the next section).

This is the import map the Orchestrator produced:

{
  "imports": {
    "@angular/core": "http://localhost:4200/angular-core-AAA.js",
    "@angular/core/rxjs-interop": "http://localhost:4200/rxjs-interop-AAB.js",
    "rxjs": "http://localhost:4200/rxjs-BBB.js",
    "mfe1/./Component": "http://localhost:4201/Component-CCC.js",
    "mfe2/./Component": "http://localhost:4202/Component-FFF.js"
  }
}

There are no scopes at all. Every app uses the host's Angular, including mfe2, because 20.1.4 fits its ^20.1.0 range. Under the v3 Classic Runtime, mfe2 loaded its own Angular because 20.1.4 and 20.1.5 weren't an exact match.

Part 4's late plugin remote, built with Angular 20.1.6, gets the same treatment. Added after startup, it only contributed its own component, and used the host's Angular and RxJS:

{ "imports": { "plugin/./Widget": "http://localhost:4203/Widget-JJJ.js" } }

Part 4's page had three copies of Angular. This one has one.

Decision 2: one build per package (4.8.0)

To understand the 4.8.0 change, you need one more idea: a package has several parts. Angular's @angular/core package includes @angular/core, @angular/core/rxjs-interop and more. As Part 3 showed, each build only includes the parts its own code imports. So two builds of "Angular 20.1.4" can contain different files.

That creates a problem. What if the host's Angular is missing a part a remote needs?

Before 4.8.0: borrowing missing parts

Up to version 4.7.x, the Orchestrator borrowed the missing part from another build and mixed it in. It assumed that the same version always means the same files. The maintainers found that wasn't true for 7 of the 24 package versions they checked (4.8.0 announcement).

Mixed copies caused real bugs. In one example, toSignal() failed with NG0203 because a borrowed rxjs-interop file talked to a different Angular runtime than the rest of the component.

Here's what 4.7.0 produced when the host's build had only @angular/core, and mfe2 (20.1.5) also used rxjs-interop:

{
  "imports": {
    "@angular/core": "http://localhost:4200/angular-core-AAA.js",
    "@angular/core/rxjs-interop": "http://localhost:4202/rxjs-interop-GGH.js",
    "rxjs": "http://localhost:4200/rxjs-BBB.js"
  }
}

The page's Angular is now the host's 20.1.4 core plus mfe2's 20.1.5 rxjs-interop: one copy, built from two different builds.

The v3 Classic Runtime could mix builds too. In my test, a remote on the exact same version as the host used the host's @angular/core together with its own rxjs-interop, inside its own scope.

In 4.8.0: one build serves each package

Version 4.8.0 replaces borrowing with a simple rule: every package is served from one build. In each share scope, the Orchestrator picks one complete copy of the package, called the serving build (one build per package):

If the host built the package, the host's copy is chosen.
If the host didn't, it picks the remote's copy that the most remotes can use, meaning the fewest extra downloads.

Then each remote is checked. If the serving build has every part the remote needs, the remote uses it. If not, the remote runs the whole package from its own build, in its own scope. Nothing is borrowed anymore.

Same files, run on 4.8.0:

{
  "imports": {
    "@angular/core": "http://localhost:4200/angular-core-AAA.js",
    "rxjs": "http://localhost:4200/rxjs-BBB.js"
  },
  "scopes": {
    "http://localhost:4202/": {
      "@angular/core": "http://localhost:4202/angular-core-GGG.js",
      "@angular/core/rxjs-interop": "http://localhost:4202/rxjs-interop-GGH.js"
    }
  }
}

Now mfe2 uses its own complete Angular 20.1.5, while RxJS is still shared. That's two copies of Angular, but each one is complete and consistent.

The trade-off

4.8.0 is safer, but it can load more. A second copy of Angular can't render its components inside the host's component tree. The maintainers measured about 0.4% more downloads on average, and import maps can grow up to twice as large when many remotes fall back to their own builds (4.8.0 announcement).

The good news: with the right build settings, you get the best of both, meaning one complete copy.

What to do now

1. Make the host's Angular complete with keepAll. It tells the build to include every part of a package, even unused ones, so the host's copy covers every remote. The config ng add generates already does this for @angular/core. From 4.8.0, .patch() accepts wildcards, so you can cover all Angular packages at once:

shared: fromPackageJson({ singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' })
  .patch(['@angular/*'], { includeSecondaries: { keepAll: true } }),

The cost is small. The browser only downloads a file when some code imports it. A real example from the docs: Angular's provideAnimationsAsync() loads part of @angular/animations with a dynamic import that the default build doesn't detect, so without keepAll the host's animations can silently never run (version resolver docs).

2. Turn on denseExternals, starting with the host. With features: { denseExternals: true }, each package is written into remoteEntry.json as one entry with one version and one range, instead of one entry per part. The Orchestrator then makes one clean decision per package. You can switch one app at a time. The maintainers expect v5 to make this the default, around the end of Q1 2027.

3. Keep build: 'package', which ng add already sets. It bundles each package on its own, so all its parts come from one bundling run.

4. Use convertFlatSharedInfo for remotes you can't rebuild yet. This host option (initFederation(manifest, { feature: { convertFlatSharedInfo: true } })) reads older remoteEntry.json files as if they were dense. It can't add parts a build left out, though. Only rebuilding with keepAll fixes that.

5. Keep remote ranges compatible with the host. If a remote's package.json says ^20.1.5 while the host is on 20.1.4, that remote can't use the host's Angular. I ran this case on 4.8.0:

With strictVersion: true, mfe2 got its own Angular in its own scope.
With strictVersion: false, mfe2 simply used the host's 20.1.4, a version its range says it doesn't support. No error stopped it.

For teams coming from v3: your remotes don't need rebuilding to switch. The settings v3 ignored are already in their remoteEntry.json files, and they start working as soon as the host runs the Orchestrator.

A note for large monorepos: one team with about 980 shared monorepo libraries reported that 4.8.0 loaded 27 of them twice, without any console errors, so they stayed on 4.7.0 for now. The cause is how library names are read. The maintainer has proposed an opt-in fix before v5 (discussion). If you share many internal libraries through sharedMappings, test 4.8.0 carefully before upgrading.

Remotes added later, and caching

Remotes added later use initRemoteEntry(), returned by initFederation(). It follows the same rules as startup and only ever adds to the import map. You saw it with the plugin remote above. In v3, the only option was a one-off loadRemoteModule({ remoteEntry }) call.

Caching has a surprising default. The Orchestrator keeps its caches in memory, so they don't survive a page reload. To keep them across reloads, choose a storage option (configuration):

import { sessionStorageEntry } from '@softarc/native-federation-orchestrator/options';

initFederation('federation.manifest.json', { storage: sessionStorageEntry });

sessionStorageEntry lasts for the browser tab's session, and localStorageEntry survives closing the browser. v3 had no caching between page loads at all.

Watch out when you turn this on: a remote redeployed at the same URL keeps its old cached remoteEntry.json, even with a cacheTag. Either deploy each build at its own URL, for example a versioned path like /mfe1/1.4.2/remoteEntry.json, or turn on the overrideCachedRemotesIfURLMatches profile option (configuration).

Trade-offs to know

The host always wins. A remote can't bring a newer compatible version to the page while the host has the package.
Strict mode is off by default, and it's all or nothing. Out of the box, a version mismatch never throws an error. You can turn on strict mode, but it then applies to every shared library at once, not just to Angular.

Both are policy decisions, and policy is what Part 6 is about: share scopes, strict mode, and how to keep many independently deployed apps from drifting apart.

Series roadmap

The Mental Model, Revisited: why Native Federation exists and what changed in v4
Anatomy of the v4 Package Graph: Core, Adapters, Runtime and Orchestrator as separate layers
Build-Time, End to End: from federation.config to remoteEntry.json
The Classic (v3) Runtime: what it got right, and where it hit its limit
The Orchestrator: how v4 decides what loads, and what changed in 4.8.0 (this article)
Version Drift and Resolution Strategy: keeping many independently deployed apps in sync
v3 vs. v4: a detailed comparison and a practical migration plan
Reference Architecture: running Native Federation v4 in a regulated enterprise

The Classic (v3) Runtime - What It Got Right, and Where It Hit Its Limit

Sakthikumaran Navakumar — Tue, 13 Oct 2026 02:36:50 +0000

Part 4 of an 8-part series on Native Federation v4 for enterprise architecture teams. New to the series? Start with Part 1: The Mental Model, Revisited.

The Classic Runtime is the browser runtime that shipped with Native Federation v3. Its package is @softarc/native-federation-runtime. It also had a short v4 line, up to version 4.1.2, before it was retired in favor of the Orchestrator (Classic Runtime docs).

Why look at a retired runtime? Because a lot of production apps still run on it, and you can't plan a move away from something you don't understand. Its behavior also explains many bugs teams have quietly learned to live with.

In Part 3, we saw what the build writes into remoteEntry.json. This article shows what the Classic Runtime does with that file in the browser, and what it ignores. Every claim links to the official docs or to the runtime's source code from its last release.

How it works, in four steps

In a v3 app, main.ts calls initFederation() before Angular starts. Then the runtime does four things (init-federation.ts):

Load the manifest, the list of remote names and URLs.
Load the host's own remoteEntry.json. The host's shared libraries go into the import map's global imports, so the whole page can use them.
Load every remote's remoteEntry.json, in parallel. Each remote's exposed modules go into the global imports. Each remote's shared libraries go into a scope: a part of the import map that only applies to files loaded from that remote's URL.
Add the import map to the page as a <script type="importmap-shim"> tag.

Why importmap-shim? A browser only accepts one normal import map per page, and the runtime may need to add more later. So it uses the es-module-shims library, which accepts several maps and merges them (v3 import map docs).

After that, loadRemoteModule('mfe1', './Component') finds the right file and loads it.

What versions can it resolve? Only exact matches

When the host and a remote both use a library, do they share one copy? The Classic Runtime decides with one simple rule. It keeps a list of the libraries it has already loaded, keyed by name and exact version (externals.ts):

function getExternalKey(shared: SharedInfo) {
  return `${shared.packageName}@${shared.version}`;
}

Same exact key already there? The remote reuses that file. The library is shared.
Anything else, even one patch version apart? The remote downloads its own copy.

The host always registers first. The v3 runtime docs put it plainly: it's "an exact match, not a semver range." In other words, the Classic Runtime resolves no version ranges at all.

Seeing it in the files

Let's follow one example from start to finish. A host and two remotes, each owned by a different team, share @angular/core and rxjs using the default config from Part 3: singleton: true, strictVersion: true and requiredVersion: 'auto'. File names are shortened.

Step 1: what each team declared in package.json

shell/package.json (the host):

"dependencies": { "@angular/core": "^20.1.0", "rxjs": "^7.8.0" }

mfe1/package.json:

"dependencies": { "@angular/core": "^20.1.0", "rxjs": "^7.8.0" }

mfe2/package.json:

"dependencies": { "@angular/core": "^20.1.0", "rxjs": "^7.8.0" }

All three are identical, so the teams look aligned. But ^20.1.0 is a range. What actually gets installed depends on when each team last ran npm install:

App	`@angular/core` installed	`rxjs` installed
shell (host)	20.1.4	7.8.2
mfe1	20.1.4	7.8.2
mfe2	20.1.5 (installed after 20.1.5 came out)	7.8.2

Step 2: what each build wrote into remoteEntry.json

The build copies the package.json range into requiredVersion and records the installed version as version.

The host, served from http://localhost:4200/:

{
  "name": "shell",
  "exposes": [],
  "shared": [
    { "packageName": "@angular/core", "outFileName": "angular-core-AAA.js",
      "version": "20.1.4", "requiredVersion": "^20.1.0", "singleton": true, "strictVersion": true },
    { "packageName": "rxjs", "outFileName": "rxjs-BBB.js",
      "version": "7.8.2", "requiredVersion": "^7.8.0", "singleton": true, "strictVersion": true }
  ]
}

mfe1, served from http://localhost:4201/:

{
  "name": "mfe1",
  "exposes": [{ "key": "./Component", "outFileName": "Component-CCC.js" }],
  "shared": [
    { "packageName": "@angular/core", "outFileName": "angular-core-DDD.js",
      "version": "20.1.4", "requiredVersion": "^20.1.0", "singleton": true, "strictVersion": true },
    { "packageName": "rxjs", "outFileName": "rxjs-EEE.js",
      "version": "7.8.2", "requiredVersion": "^7.8.0", "singleton": true, "strictVersion": true }
  ]
}

mfe2, served from http://localhost:4202/:

{
  "name": "mfe2",
  "exposes": [{ "key": "./Component", "outFileName": "Component-FFF.js" }],
  "shared": [
    { "packageName": "@angular/core", "outFileName": "angular-core-GGG.js",
      "version": "20.1.5", "requiredVersion": "^20.1.0", "singleton": true, "strictVersion": true },
    { "packageName": "rxjs", "outFileName": "rxjs-HHH.js",
      "version": "7.8.2", "requiredVersion": "^7.8.0", "singleton": true, "strictVersion": true }
  ]
}

requiredVersion is the same everywhere. Only version differs, and only for mfe2's Angular.

Step 3: the import map the runtime adds to the page

I ran the Classic Runtime's own initFederation() code against these three files. This is exactly what it produced:

{
  "imports": {
    "@angular/core": "./angular-core-AAA.js",
    "rxjs": "./rxjs-BBB.js",
    "mfe1/Component": "http://localhost:4201/Component-CCC.js",
    "mfe2/Component": "http://localhost:4202/Component-FFF.js"
  },
  "scopes": {
    "http://localhost:4201/": {
      "@angular/core": "./angular-core-AAA.js",
      "rxjs": "./rxjs-BBB.js"
    },
    "http://localhost:4202/": {
      "@angular/core": "http://localhost:4202/angular-core-GGG.js",
      "rxjs": "./rxjs-BBB.js"
    }
  }
}

How it all connects

imports holds the host's libraries and every remote's exposed modules. mfe1/Component is the name loadRemoteModule('mfe1', './Component') looks up.
mfe1's scope points at the host's files. Both its versions matched exactly, so it shares Angular and RxJS. Its own copies are never downloaded.
mfe2's scope is mixed. RxJS 7.8.2 matched, so it's shared. Angular 20.1.5 didn't match 20.1.4, so mfe2 loads its own copy of Angular, even though ^20.1.0 allows both.
singleton and strictVersion left no trace, even though every file set them to true.

You can check this in your own app. In DevTools, find the importmap-shim script in the page's <head> and compare its scopes with the remoteEntry.json files in the network tab.

Your lockfile decides, not your package.json

Look at what happened to mfe2. The team changed no code and no config. They simply installed later, and production got a second copy of Angular. The same happens when a CI pipeline or a dependency bot updates a lockfile. Under the Classic Runtime, the installed version decides what gets shared.

Scale this up and it gets worse. With one host and six remotes spread over a few patch versions, a page can easily end up with four copies of Angular:

Remotes the host doesn't know up front

Both setups from Part 3 work the same way here. Remote URLs written in main.ts, or a federation.manifest.json fetched at startup: either way, the list is known before the app starts, and the four steps run as described.

For a remote found later, such as a plugin a user turns on, the only option is to pass its remoteEntry.json URL to loadRemoteModule():

await loadRemoteModule({
  remoteEntry: 'http://localhost:4203/remoteEntry.json',
  exposedModule: './Widget',
});

I tested this with a plugin remote whose lockfile installed Angular 20.1.6. The runtime fetched its remoteEntry.json, applied the same exact-match rule, and added a second import map (load-remote-module.ts):

{
  "imports": { "plugin/Widget": "http://localhost:4203/Widget-JJJ.js" },
  "scopes": {
    "http://localhost:4203/": {
      "@angular/core": "http://localhost:4203/angular-core-KKK.js",
      "rxjs": "./rxjs-BBB.js"
    }
  }
}

Same rule, same result: RxJS is shared, Angular is not. The first map is never changed. Two limits are worth knowing:

It's a one-off, tied to loading a module. You can't register a remote in advance.
The short form loadRemoteModule('plugin', './Widget') fails until the remote has been registered this way.

The docs list this as "No dynamic init" (Classic Runtime docs). The Orchestrator adds initRemoteEntry() for it, covered in Part 5.

Your federation.config settings don't apply here

When building the import map, the Classic Runtime reads only three fields of each shared library: packageName, version and outFileName. You can see this in init-federation.ts. I searched every release I could find, from 16.3 to the last one, and the other settings appear only in type definitions and in get-shared.ts, a helper for working alongside webpack.

So under the Classic Runtime:

singleton: true doesn't stop a second copy of Angular.
strictVersion: true doesn't raise an error.
requiredVersion: '^20.1.0' doesn't let 20.1.5 share with 20.1.4.

If you've seen strictVersion errors before, they came from somewhere else. webpack Module Federation throws "Unsatisfied version … of shared singleton module …" when strictVersion is on. The Orchestrator can throw an NFError in strict mode.

But ignored doesn't mean wasted. The build still writes these settings into remoteEntry.json, and the Orchestrator acts on them. Switch runtimes, and they start working without rebuilding a single remote.

Why duplicate copies hurt

A second copy of a small utility just costs download time. For anything that holds state, it causes real bugs:

Angular expects to be alone on the page. Two copies break dependency injection, often with errors like NG0203.
Stateful libraries, like a store or an auth client, end up with two separate instances. The host logs the user in, and the remote never finds out.

These bugs are hard to trace, because each app works fine on its own.

What it got right

To be fair, the Classic Runtime got a lot right:

It's built on web standards, ES modules and import maps, which v4 kept.
It's simple and predictable. One rule, easy to follow once you know it.
Scopes protect the host. An incompatible remote gets its own copy instead of replacing the host's.
It has useful extras: a fallback option in loadRemoteModule(), a cacheTag option for cache busting, and automatic reloads during development.

Where it hit its limit

The organizational cost. To share Angular, every team must ship the exact same patch version. Upgrading from 20.1.4 to 20.1.5 is no longer one team's decision. It has to be planned and released together across the host and every remote. That's lockstep releasing, which works against the main promise of micro frontends: teams that deploy independently.

The operational gaps, as listed in the Classic Runtime docs:

No caching between page loads. Every remoteEntry.json is fetched again on every load.
Silent failures. A remote that fails at startup is only logged to the console, and the app starts without it.
No share scopes to keep one team's libraries separate from another's.

Living with it until you migrate

If you're still on the Classic Runtime:

Find your duplicates by checking the importmap-shim scripts in DevTools.
Pin exact versions of Angular and other stateful libraries, and update them in every repository together.
Send browser console errors to your monitoring, so a remote that fails at startup raises an alert.

Then plan the move. The Orchestrator reads the same remoteEntry.json files, so remotes don't need to change. Part 7 covers the migration.

What Part 5 answers

The Classic Runtime leaves three open questions:

How do you share a library across a range of versions?
How do you make singleton and strictVersion actually do something?
How do you avoid fetching everything again on every page load?

The Orchestrator was built to answer all three. Part 5 opens it up.

Series roadmap

The Mental Model, Revisited: why Native Federation exists and what changed in v4
Anatomy of the v4 Package Graph: Core, Adapters, Runtime and Orchestrator as separate layers
Build-Time, End to End: from federation.config to remoteEntry.json
The Classic (v3) Runtime: what it got right, and where it hit its limit (this article)
The Orchestrator: how version resolution and caching work, in depth
Version Drift and Resolution Strategy: keeping many independently deployed apps in sync
v3 vs. v4: a detailed comparison and a practical migration plan
Reference Architecture: running Native Federation v4 in a regulated enterprise

Build-Time, End to End - From federation.config to remoteEntry.json

Sakthikumaran Navakumar — Tue, 06 Oct 2026 02:00:49 +0000

Part 3 of an 8-part series on Native Federation v4 for enterprise architecture teams. New to the series? Start with Part 1: The Mental Model, Revisited.

In Part 2, we mapped the four layers of Native Federation v4 and saw that one file, remoteEntry.json, connects the build to the browser. This article zooms in on the build side and answers three questions:

What do you write in federation.config.mjs, and what does each setting mean?
What happens, step by step, when you run the build, and what files come out?
How does a host find remotes it has never seen when it was built?

Everything here is based on the official docs and the source code of native-federation-core and the Angular adapter, and links point to both so you can check the details yourself.

A few terms first

Part 2 explained host, remote, shared dependency, bundler, import map, semver and singleton. This article adds four more:

External: a library that is deliberately left out of your app's bundle, so it can be loaded separately and shared.
Exposed module: a piece of your app, such as a component or a set of routes, that other apps are allowed to load.
Entry point: the file a build or a code scan starts from. In Angular, that's usually src/main.ts.
Manifest: a list of remote names and the URLs of their remoteEntry.json files.

Normal build vs. federated build

In a normal Angular build, your code and every library you use are bundled together. If three apps all use Angular, users download Angular three times.

A federated build splits things up. Your own code is built without the shared libraries inside it. Each shared library gets its own file, so the browser can download it once and reuse it. And the build writes two small description files, remoteEntry.json and importmap.json, so the browser knows what's available.

The input: federation.config.mjs

Every federated project has a federation.config.mjs next to it. Here is the one the Angular adapter's ng add schematic generates for a remote today, taken from its template in the source code (comments shortened):

import { withNativeFederation, fromPackageJson } from '@angular-architects/native-federation/config';

export default withNativeFederation({
  name: 'mfe1',

  exposes: {
    './Component': './src/app/app.component.ts',
  },

  shared: fromPackageJson({ singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' })
    // Share all of @angular/core to prevent version mismatches
    .patch(['@angular/core'], { includeSecondaries: { keepAll: true } }),

  skip: ['rxjs/ajax', 'rxjs/fetch', 'rxjs/testing', 'rxjs/webSocket'],

  features: {
    denseChunking: true,
  },
});

Let's go through it piece by piece.

Choosing what to share

There are three ways to build the shared list, all defined in share-utils.ts:

fromPackageJson() is the recommended way. It reads the dependencies in your package.json and shares all of them with the settings you pass in. Exceptions are handled with .skip(), .override() and .patch(). The example above uses .patch() to change the settings of just @angular/core.
shareAll() is the older version of the same idea. It still works.
share() is for picking libraries by hand, one by one.

If you leave shared out entirely, Native Federation behaves as if you had written fromPackageJson({ singleton: true, strictVersion: true, requiredVersion: 'auto' }) (Core configuration).

The settings on each library

Each shared library carries four settings that matter later, when the browser decides which version to load:

singleton: only one copy of this library may exist on the page. Frameworks like Angular need this.
strictVersion: if another app needs a version that isn't compatible, don't just use the shared one anyway.
requiredVersion: the range of versions this app accepts. 'auto' means "use the range from package.json," for example ^20.1.0.
version: the exact version this app was built with. By default it's read from the installed package in node_modules, not from package.json.

Here's how that plays out. Say your package.json lists "@angular/core": "^20.1.0" and npm install gave you 20.1.4. The build records that this app has 20.1.4 and accepts anything from ^20.1.0. The browser later uses both numbers to find one version every app can agree on. Part 5 covers that decision in detail.

Notice that the defaults are strict. Unless you change them, every library is shared as a strict singleton. That's safe, but it's worth knowing before you see your first version warning.

skip: leaving a library out of sharing

skip takes package names, regular expressions or small functions. The important detail: skipping a library does not remove it. It still gets installed and still works, but it's built into your app's own bundle instead of being shared. The template above skips parts of RxJS that most apps never use at runtime.

Some packages are skipped automatically, through a default skip list: Native Federation's own packages, es-module-shims and all @types/* packages.

includeSecondaries and keepAll: the sub-paths

Many libraries have sub-paths, called secondary entry points, like @angular/common/http or @angular/core/rxjs-interop. includeSecondaries controls whether those are shared too.

Setting includeSecondaries: { keepAll: true } goes one step further. It tells the build to keep every sub-path of a library as long as the library itself is used, even sub-paths your app never imports. The next section explains why the template does this for @angular/core.

How the build decides what's "used"

Sharing everything in package.json would be wasteful. Most projects list libraries they barely touch. So Native Federation has a feature called ignoreUnusedDeps, which is on by default (with-native-federation.ts). It scans your code, finds which shared libraries are actually imported, and drops the rest from the shared list.

The interesting question is where the scan starts. The answer depends on whether the project is a host or a remote, and it's easy to get wrong.

If the project exposes modules (a remote), the scan starts from the exposed files only. It does not look at main.ts or bootstrap.ts at all. You can see this in get-used-dependencies.ts: it takes the files listed in exposes, and only uses the fallback entry points when that list is empty. The Angular builder's entryPoints option confirms this. Its description says exposed modules "always take precedence," so you can't use it to override or narrow them.

If the project exposes nothing (a typical host), the scan starts at src/main.ts. In a federated Angular app, main.ts is tiny. It starts federation, then loads the real app with a dynamic import:

initFederation('federation.manifest.json', { hostRemoteEntry: { url: './remoteEntry.json' } })
  .catch(err => console.error(err))
  .then(_ => import('./bootstrap'))
  .catch(err => console.error(err));

The scanner uses TypeScript's import detection, which sees dynamic import() calls as well as normal imports. So it follows import('./bootstrap') into bootstrap.ts, then into your app config, your routes, and the components those routes lazy-load. Anything reachable from there counts as used.

Then the scan adds what your libraries need. If you use @angular/router, the build also counts the packages @angular/router itself imports, such as @angular/common.

Finally, sub-paths are checked. Without keepAll, a sub-path like @angular/core/rxjs-interop is kept only if something imports it exactly. With keepAll, it's kept whenever its parent package is used (remove-unused-deps.ts).

That last rule is why the template sets keepAll on @angular/core. Imagine two remotes on different Angular patch versions, where only one of them imports @angular/core/rxjs-interop. The other remote drops that sub-path from its build. At runtime, the page can end up loading @angular/core from one version and rxjs-interop from another, splitting Angular across versions. The Core configuration docs warn about exactly this, and keepAll on framework libraries is the fix.

What this means for remotes: a library used only by a remote's own startup code, in main.ts or bootstrap.ts, isn't shared by that remote. It still works, because it's bundled into the remote instead. But if you expected the host and the remote to share it, check the remote's remoteEntry.json rather than assuming.

What happens when you build

With the config understood, here's what actually runs when you type ng build. The order comes from the Angular adapter's builder documentation and its source.

Read the config. withNativeFederation() fills in defaults, applies the skip list and works out the shared list.
Find what's used. The ignoreUnusedDeps scan from the previous section trims the shared list.
Build the shared libraries. Each one becomes its own file. Built libraries are cached in node_modules/.cache/native-federation/<project>, so the next build can reuse them. The cache refreshes itself when installed versions or sharing settings change (Core caching).
Build the exposed modules.
Write remoteEntry.json and importmap.json.
Hand off to Angular. The adapter is a thin wrapper around Angular's own ApplicationBuilder. Angular builds your app as usual, with the shared libraries marked as externals so they stay out of your bundle.

Two practical notes. If the Angular build fails, no federation files are written at all, so a failing build can never ship a half-updated remoteEntry.json. And if a build ever looks stale, deleting node_modules/.cache/native-federation forces a clean rebuild of the shared libraries.

The output: remoteEntry.json and importmap.json

remoteEntry.json: what this app offers and needs

This is the file other apps read. Its shape is defined in federation-info.contract.ts and written by write-federation-info.ts. A simplified example (real file names include content hashes and will differ):

{
  "$version": "v4",
  "name": "mfe1",
  "exposes": [
    { "key": "./Component", "outFileName": "Component-HASH.js" }
  ],
  "shared": [
    {
      "packageName": "@angular/core",
      "outFileName": "angular-core-HASH.js",
      "version": "20.1.4",
      "requiredVersion": "^20.1.0",
      "singleton": true,
      "strictVersion": true
    }
  ]
}

Every setting from the config shows up here. version is what this app was built with, and requiredVersion is what it accepts. singleton and strictVersion tell the browser how strict to be. The $version: "v4" marker tells runtimes which manifest format they're reading. With denseChunking turned on, there's also a chunks section listing the split code files.

importmap.json: this app's own view

The build also writes an importmap.json (write-import-map.ts). It maps each shared library to the file that holds it:

{
  "imports": {
    "@angular/core": "angular-core-HASH.js",
    "rxjs": "rxjs-HASH.js"
  }
}

The mental model docs describe it as "this project's view of where its externals live." The key word is this project's. It only knows about one app. The import map that actually runs in the browser is built later, by the runtime, from the remoteEntry.json files of the host and every remote together.

Static and dynamic remotes

This is the part that surprises people coming from webpack Module Federation: a Native Federation host never looks at its remotes during the build. It doesn't fetch them, check them, or link against them. The only question is where the host finds the remote URLs at runtime, and the ng add schematic gives you two choices through --type (Angular adapter getting started).

Static remotes (--type host). The remote URLs are written straight into main.ts as an object. The schematic source generates something like this:

initFederation({
  'mfe1': 'http://localhost:4201/remoteEntry.json'
}, { hostRemoteEntry: { url: './remoteEntry.json' } })

It's simple, but the URLs are now part of your host's code. Moving a remote to a new URL, or deploying the same host to test and production, means rebuilding the host.

Dynamic remotes (--type dynamic-host, the recommended default). The URLs live in a federation.manifest.json in your public/ folder:

{
  "mfe1": "http://localhost:4201/remoteEntry.json"
}

main.ts just passes the file name, initFederation('federation.manifest.json', ...), and the manifest is fetched when the app starts. The same host build can run in every environment. Only the manifest changes, and it can even be generated by your deployment pipeline.

Remotes discovered later. Sometimes nobody knows the full list of remotes up front, as in a plugin system where customers enable features. The Orchestrator handles this with initRemoteEntry(), which adds a remote after the app has started (Orchestrator getting started). It only ever adds to the import map and never changes decisions already made.

Two more details from that generated main.ts are worth noticing:

The host publishes its own remoteEntry.json. Every generated main.ts passes hostRemoteEntry: { url: './remoteEntry.json' }. That's the host's own build output, and at runtime the host's versions win whenever a library appears in both the host and a remote (Orchestrator configuration).
A remote can run on its own. A remote's main.ts calls initFederation({}, ...) with an empty list. It acts as its own host, which is why you can open a remote in the browser and work on it alone.

Where version resolution fits

Everything in this article happens at build time, and the build never chooses a version. It only records them: which version each app has, which range it accepts, and how strict it wants to be. The choosing happens in the browser, when the runtime reads all the remoteEntry.json files together. Part 4 looks at how the Classic Runtime made that choice, and why it often ended up loading two copies of Angular. Part 5 shows how the Orchestrator does it properly.

Key takeaways

federation.config.mjs decides what is shared and how strictly. By default, everything is a strict singleton.
skip doesn't remove a library. It just stops it from being shared.
With ignoreUnusedDeps (on by default), a host is scanned from main.ts through bootstrap.ts, while a remote is scanned from its exposed modules only.
Use includeSecondaries: { keepAll: true } on framework libraries, so sub-paths can't split a framework across versions.
The build writes remoteEntry.json (what this app offers and needs) and importmap.json (this app's own view).
A host never looks at remotes during the build. Prefer dynamic-host so one build can serve every environment.

Series roadmap

The Mental Model, Revisited: why Native Federation exists and what changed in v4
Anatomy of the v4 Package Graph: Core, Adapters, Runtime and Orchestrator as separate layers
Build-Time, End to End: from federation.config to remoteEntry.json (this article)
The Classic Runtime: what it got right, and where it hits its limit
The Orchestrator: how version resolution and caching work, in depth
Version Drift and Resolution Strategy: keeping many independently deployed apps in sync
v3 vs. v4: a detailed comparison and a practical migration plan
Reference Architecture: running Native Federation v4 in a regulated enterprise

Anatomy of the v4 Package Graph - Core, Adapters, Runtime, and Orchestrator

Sakthikumaran Navakumar — Wed, 30 Sep 2026 01:31:47 +0000

Part 2 of an 8-part series on Native Federation v4 for enterprise architecture teams. New to the series? Start with Part 1: The Mental Model, Revisited.

In Part 1, I discussed how Native Federation v4 is a platform, not just a plugin. The main evidence was that v4 split the project into several separate packages, each with its own version.

🤖 A note on this article: I used Claude to help reformat and structure the content to make it clearer and more presentable for publication.

But splitting code into more packages doesn't prove much on its own. The split only matters if each package has a clear job, and if you can upgrade or replace one package without breaking the others.

This article tests that. It walks through the four layers of Native Federation v4 (Core, Adapters, the Classic Runtime and the Orchestrator), explains what each one is responsible for, and shows the one contract that connects them. The rest of the series builds on this map.

A few terms first

If you're new to micro frontends, these terms appear throughout the article:

Host: the main application (often called the "shell") that loads other applications into itself.
Remote: a separately built and deployed application that the host loads at runtime.
Shared dependency: a library, like Angular or RxJS, that the host and remotes all use. Ideally the browser downloads it once and everyone reuses it.
Bundler: the tool that turns your source code into files the browser can run, such as esbuild or webpack.
Import map: a standard browser feature. It's a small JSON block on the page that tells the browser where to find a module. For example: "when code asks for rxjs, load it from this URL."
Semantic versioning (semver): the major.minor.patch version format. A range like ^18.0.0 means "any 18.x version is fine."
Singleton: a library that must exist only once on the page. Angular is the classic example: two copies of Angular on one page cause errors.

From one plugin to four repositories

Native Federation used to live inside the angular-architects/module-federation-plugin repository, alongside the same team's webpack Module Federation tools. For v4, the maintainers moved it into its own GitHub organization and split it into four repositories (v3 vs v4):

native-federation-core: the core logic. It doesn't depend on any framework or bundler.
esbuild-adapter: connects the core to the esbuild bundler.
angular-adapter: connects the core to Angular's build tools.
orchestrator: loads remotes in the browser.

For each one below, we'll ask the same question: what does it own, and what does it deliberately leave to the others?

The four layers

Core: runs at build time, and only at build time

The core package is @softarc/native-federation. It doesn't know about Angular, esbuild, or how a browser loads a remote. The official architecture overview describes its job in one line: it "normalizes the federation config, bundles shared dependencies and exposed modules, and emits remoteEntry.json + the import map."

That job has three parts.

1. It defines the configuration. Every federated project, whatever framework it uses, is described with the same functions (Core configuration):

withNativeFederation() holds the whole configuration: the app's name, the modules it exposes to other apps, and the libraries it shared.
fromPackageJson() is the recommended way to list shared libraries. It shares everything in your package.json, and lets you handle exceptions with .skip(), .override() and .patch(). The older shareAll() still works.
Each shared library gets a few settings that matter later, when the browser decides which version to load: singleton (only one copy allowed), strictVersion (versions must match), requiredVersion (the acceptable range, where 'auto' reads it from package.json) and includeSecondaries (whether to also share sub-paths like @angular/common/http).
sharedMappings handles monorepos, where internal libraries are shared through TypeScript path aliases.

2. It plans the build, but doesn't run the bundler. Core decides what to build. Your app is built without the shared libraries inside it, and each shared library is built separately, so the browser can download it once and reuse it. Core never compiles your code itself. It hands that work to an adapter (Core getting started).

3. It writes the manifest. Core's most important output is a file called remoteEntry.json. Think of it as a remote's label. It lists what the remote exposes and which files contain it. It also lists every shared library, with the version it was built with, the version range it accepts, and its singleton and strictVersion settings.

v4 adds two optional settings that keep this file small in large projects. features.denseChunking groups split code files by bundle, and features.denseExternals groups all the entry points of one library into a single entry (Core configuration).

What Core does not do matters just as much. It doesn't turn TypeScript into JavaScript, and it doesn't decide which library version the browser loads. Because its job is small and clear, it can stay stable while everything around it changes.

Adapters: connect a specific tool to Core

Core works with any bundler in principle, but something has to connect it to a real one. That's all an adapter does. There are two kinds.

Bundler adapters connect Core to one bundler. The esbuild adapter, @softarc/native-federation-esbuild, is the reference one.

This adapter also solves a common real-world problem: CommonJS. Browsers run modern JavaScript modules (ES modules, or ESM). Some popular libraries, React most famously, are still published in the older CommonJS format. The adapter includes a plugin, @chialab/esbuild-plugin-commonjs, that converts them, and its default React setup turns it on for you. The docs also cover libraries that still don't convert cleanly (esbuild adapter getting started). If your project uses older CommonJS libraries, this is where you'll run into them.

Framework adapters make Native Federation feel like a normal part of a framework's tools. The Angular adapter is the most mature. It plugs into angular.json and hands the actual build to Angular's own ApplicationBuilder. So you get every build improvement the Angular team ships, without a separate build process.

You set it up with ng add. The --type option decides what you're creating (Angular adapter getting started):

remote: a micro frontend.
host: a shell for one environment.
dynamic-host: a shell that reads its list of remotes at runtime. This is the recommended default.

The schematic updates angular.json, moves your startup code into a bootstrap.ts file, and creates a federation.config.mjs.

Two details help with planning. First, the Angular adapter's version numbers follow Angular's, so keep them on the same major version. On Angular 20 and 21, v4 is published as @angular-architects/native-federation-v4. From Angular 22, it's back under the original name, @angular-architects/native-federation (Angular adapter getting started). Second, an adapter only translates between a tool and Core. When the Angular adapter changes, it's usually because Angular's build tools changed, not because Core did.

Adapters are the layer most teams work with every day: running the schematic, editing the config, and upgrading with each Angular release.

Classic Runtime: the original browser loader

The Classic Runtime, @softarc/native-federation-runtime, is what most existing projects still use in the browser. Its design was simple. In the words of the docs, it "read remoteEntry.json files, merged them into one ES module import map, injected it into the DOM, and resolved loadRemoteModule() calls against it" (Runtime docs).

In practice, you call initFederation() in the host before the app starts, then call loadRemoteModule() whenever you need a remote. It uses a small library called es-module-shims so import maps work reliably, which is why the startup code is split into main.ts and bootstrap.ts.

The catch is that it doesn't negotiate versions. It has no semver resolution and no caching between page loads (Orchestrator docs). When two remotes want different versions of a library, the docs say they "simply each kept their own" (Runtime docs).

For a small utility library, that just costs extra download time. For a framework, it breaks things. Say the host is built with Angular 18.1.0 and a remote with Angular 18.1.1. The page ends up with two copies of Angular, and you get NG0203 errors (Angular's "injection context" error). Many teams have hit this in production.

The Classic Runtime is now deprecated and end-of-life. The last version is 4.1.2, and its npm page tells users to switch to the Orchestrator (Runtime docs). Existing projects keep working, but there will be no more fixes. Part 4 looks at why its design hit a limit.

Orchestrator: the new browser loader

The Orchestrator, @softarc/native-federation-orchestrator, reads the same remoteEntry.json files as the Classic Runtime. The difference is that it actually decides which version of each library to load (Orchestrator docs).

You pass it around instead of importing it. initFederation(manifest, options) gives you back an object that includes loadRemoteModule, load and initRemoteEntry. You pass that object into your app rather than importing a global function. In Angular, the docs do this with an InjectionToken, so it works through normal dependency injection. The options control logging, storage and how strict version checks are (Orchestrator getting started; configuration).

It remembers what it has already loaded. The Orchestrator keeps four caches (architecture):

where each remote lives and what it exposes
shared libraries, grouped by package
private libraries that belong to a single remote
shared code chunks (new in v4)

By default these caches are kept in memory. You can save them with sessionStorageEntry or localStorageEntry, so the next page load doesn't start from scratch (getting started). This helps most with server-rendered sites that reload the whole page on every click.

It picks versions in three steps (version resolver):

Sort. Libraries not marked as singletons skip the negotiation, and each remote simply gets its own copy. Singletons go into a group called a share scope. There's a global scope by default. You can create named scopes, such as "team-a", so one team's libraries never compete with another team's. There's also a special "strict" scope, where every requested version is kept exactly as-is.
Choose. Within each scope, one version of each library wins. If the host declares a version, the host always wins. Otherwise, by default, the Orchestrator picks the version that causes the fewest extra downloads. You can switch that to "pick the newest version" with the latestSharedExternal setting. Remotes that asked for an incompatible version are then handled in one of two ways. With strictVersion: false (the default), they use the winning version anyway and a warning is logged. With strictVersion: true, they download their own private copy.
Write the import map. The winning versions go into the import map's imports section. Private copies go into scopes, a per-remote section. Optional security hashes go into integrity (architecture).

If more remotes show up after the app starts, initRemoteEntry() adds them. It only ever adds to the import map. It never changes a decision that was already made.

Two design choices are worth knowing about early (version resolver):

Strictness is all or nothing. You turn on strict.strictExternalCompatibility once, in the options for initFederation(). When it's on, every version mismatch throws an error instead of a warning. You can't be strict about Angular and relaxed about a small utility library in the same scope.
The host's version always wins. If a remote ships a newer, compatible patch, the page still loads the host's version.

Neither is a bug. They are deliberate choices, and they affect how you should set up your share scopes. Parts 5 and 6 cover this in depth.

The one contract that connects everything

Core and the adapters run at build time, before you deploy. The Classic Runtime and the Orchestrator run later, in the user's browser. The only thing passed from one side to the other is the manifest, remoteEntry.json.

The architecture overview puts it this way: "the Core and Runtime speak a simple contract — remoteEntry.json plus an import map. Everything else (which bundler, which framework, which runtime) is swappable" (architecture overview).

This is the most important idea in this article. Core doesn't need to know which runtime will read its output. It just writes a manifest in an agreed format. The runtimes don't need to know about each other, or about which Core version wrote a manifest. They just read that format.

That's why the split into separate packages actually works. In practice, it means:

You can upgrade Core without every team having to change its runtime at the same time.
During a migration, one app can use the Classic Runtime while another uses the Orchestrator, both reading manifests from the same Core version.
The Orchestrator can load v3 and v4 remotes on the same page, because both follow the same contract (Orchestrator docs).

Part 7's migration plan depends on exactly this.

Quick reference: which package does what

Keep this table handy. It's useful mid-migration, when you're looking at a lockfile and trying to work out what you're actually running.

Package	Layer	Status	Responsible for
`@softarc/native-federation`	Core	Active	Configuration, build planning, the `remoteEntry.json` format
`@softarc/native-federation-esbuild`	Bundler adapter	Active	Connecting esbuild, converting CommonJS libraries
`@angular-architects/native-federation` (Angular 22+) / `-v4` (Angular 20–21)	Framework adapter	Active	Connecting Angular's build tools, schematics
`@softarc/native-federation-runtime`	Runtime (classic)	Deprecated, end-of-life	Loading remotes with one merged import map, no version negotiation
`@softarc/native-federation-orchestrator`	Runtime (v4)	Active, recommended	Loading remotes, choosing versions, share scopes, caching

Check your own project

Before Part 3 looks at what happens during the build, take five minutes to check your own project. Open package.json or your lockfile and look for these:

Core: which version you're on, and how far behind the latest release it is.
Adapter: which adapter you use, and whether its major version matches your Angular version. On Angular 20 or 21, check whether you're on the -v4 package or still on v3.
Runtime: whether you use the Classic Runtime or the Orchestrator. If you see @softarc/native-federation-runtime, you depend on a package that no longer gets fixes. Plan the move now, not after the next incident.
Config file: whether your config is still federation.config.js using require() and module.exports. v4 expects federation.config.mjs, written as an ES module, so the old style means your setup predates v4 (migration guide).

This check sounds basic, but it catches the most common problem teams hit when adopting v4. Usually the hard part isn't the concepts. It's finding out halfway through a migration that one layer is several versions behind where everyone thought it was.

Series roadmap

The Mental Model, Revisited: why Native Federation exists and what changed in v4
Anatomy of the v4 Package Graph: Core, Adapters, Runtime and Orchestrator as separate layers (this article)
Build-Time, End to End: what Core and the adapters actually do to your code
The Classic Runtime: what it got right, and where it hits its limit
The Orchestrator: how version resolution and caching work, in depth
Version Drift and Resolution Strategy: keeping many independently deployed apps in sync
v3 vs. v4: a detailed comparison and a practical migration plan
Reference Architecture: running Native Federation v4 in a regulated enterprise

References

Official documentation

Articles by the maintainers

Auke van Oostenbrugge, Part II: Composing your own native-federation orchestrator
Auke van Oostenbrugge, Part III: Improving Cache Utilization in Native Federation
Auke van Oostenbrugge, Tweaking native-federation, Part II: Sharing externals

Next in this series: **Build-Time, End to End, what Core and the adapters actually do to your code.

Native Federation - Deep Dive - Part 1/8 - The Mental Model, Why Native Federation Exists and What Changed in v4

Sakthikumaran Navakumar — Sat, 19 Sep 2026 01:05:01 +0000

Part 1 of an 8-part series on Native Federation - A deep dive.

🤖 A note on this article: I used Claude to help reformat and structure the content to make it clearer and more presentable for publication.

If you've shipped a production micro-frontend system on webpack Module Federation, you already know the mental model: a host application lazy-loads code it never saw at compile time, from a remote it doesn't own, and the two negotiate shared dependencies at runtime so you're not shipping three copies of React down the wire. Native Federation didn't invent that model — it inherited it deliberately, because the model was never the problem. The implementation was.

This article isn't going to re-teach you what a remote is. It's going to explain why an entire second implementation of the same mental model was worth building, what structural debt it paid off, and what the v4 rewrite tells us about where the project — and the pattern — is heading. Everything that follows in this series (Core, Adapters, the Orchestrator, version drift, migration) is downstream of the argument in this article, so it's worth getting precise about it before we go deep on any one subsystem.

The compromise nobody talked about

Webpack Module Federation is, technically, remarkable. It solved cross-application dynamic linking inside a tool that was never designed for it, wrapping every federated module in a runtime container and negotiation layer that webpack manages on your behalf. It works. Thousands of production systems prove it works.

But it works inside webpack's universe. Every remote, every host, every build step in that architecture is mediated by webpack's own module runtime — its own resolution logic, its own chunk-loading machinery, its own container format. That's not a criticism of the implementation; it's an acknowledgment of what problem webpack was actually solving when it introduced Module Federation: how do you retrofit dynamic, runtime remote loading onto a bundler whose entire value proposition is static dependency analysis at build time? The container pattern is the necessary compromise.

The compromise has a cost, and if you've operated Module Federation at scale, you've paid it:

Framework lock-in at the tooling layer. Your host and every remote are implicitly committed to webpack (or a webpack-compatible bundler) for the life of the federated system, because the runtime contract is a webpack runtime contract.
A parallel module system living alongside the real one. The browser has a native module system — ES Modules — that has matured enormously in recent years. Module Federation doesn't use it; it builds its own resolution and loading logic on top of webpack.
Migration friction that compounds. Moving a host off webpack — to Vite, to esbuild, to whatever ships next — means either dragging Module Federation's runtime along as a dependency of a tool you're trying to leave, or re-architecting your federation layer as part of a bundler migration. Two hard problems, coupled.

None of this made Module Federation the wrong choice when it was the only serious option. It made it a choice with an expiration date tied to how long webpack stayed the default.

What "browser-native" actually buys you

Native Federation's core bet is structural: instead of building a container protocol on top of a bundler's runtime, build directly on ECMAScript Modules and Import Maps — both of which are web standards the browser already implements, with no bundler runtime mediating the load.

Concretely, that means:

A remote's exposed module is a genuine ES module, served as a genuine .js file, importable with a genuine dynamic import().
Shared dependency resolution happens through the browser's import map mechanism — a JSON structure that tells the browser "when code asks for react, resolve it to this URL" — rather than through a bundler-authored sharing runtime.
The build tool's job shrinks to what a build tool should do: produce standards-compliant output and a manifest (remoteEntry.json) describing what's exposed and what's shared. It stops being responsible for how the browser resolves modules at runtime, because the browser already knows how to do that.

This is the part that's easy to undersell as "just an implementation detail," but for an architecture team it's the whole point: the bundler becomes replaceable. Native Federation ships a reference esbuild adapter and — most maturely — an Angular adapter that hooks directly into Angular's own esbuild-based Application Builder, but the underlying contract (ESM + import maps + a JSON manifest) doesn't require any of that. Swap the build tool, keep the federation contract. That's not true of container-based Module Federation, and it's the single biggest reason to treat this as an infrastructure decision independent of your current framework and bundler choices — not just an Angular-ecosystem convenience.

Why this matters more in v4 than it did in v3

Native Federation existed well before v4, largely as a feature of the Angular CLI plugin ecosystem — genuinely useful, but organizationally still shaped like "a clever thing the Angular Architects team built for Angular users." v3 proved the ESM/import-map model worked in production.

v4 is the rewrite that makes that claim credible, and the evidence isn't a changelog bullet point — it's organizational. The project moved out of the original angular-architects/module-federation-plugin monorepo entirely and now lives under its own GitHub organization, split into independently versioned repositories: a framework-and-bundler-agnostic core, a dedicated esbuild adapter, a dedicated Angular adapter, and a separately maintained orchestrator for runtime consumption.

That's not cosmetic restructuring. It's the difference between "a plugin with internal modules" and "a platform with published contracts between its layers." When a build tool, a framework adapter, and a runtime consumer are three separately versioned artifacts instead of three files in the same package, you get to ask a much sharper architectural question about any given piece of the system: what does this layer promise to the layer above it, and what can I swap out without breaking that promise? We'll answer that question concretely for every layer over the next two articles.

The other structural signal in v4 worth naming now, because it recurs throughout this series: the project explicitly frames itself as moving toward first-class support for frameworks beyond Angular, and toward runtime consumption from environments that aren't single-page applications at all — plain HTML pages, and server-rendered hosts in different ecosystems, consuming the same manifest contract. Angular remains the most mature adapter today by a wide margin, and this series will go deep on it because that's where the tooling is production-ready — but the ceiling of the architecture is no longer "an Angular thing." That ceiling matters when you're making a five-year platform bet, not just a next-quarter delivery decision.

Series Roadmap

This is an 8-part series, and each article builds on the ones before it. Here's the full plan, and where we are right now:

The Mental Model, Revisited — why Native Federation exists and what changed in v4 (this article)
Anatomy of the v4 Package Graph — Core, Adapters, Runtime, and Orchestrator as independently versioned layers
Build-Time, End to End — the Core library and its Adapters, and what they actually do to your code
The Classic Runtime — what it got right, and where it hits its ceiling
The Orchestrator — semver-aware resolution and persistent caching, under the hood
Version Drift and Resolution Strategy — the governance problem nobody's build pipeline catches
v3 vs. v4 — a systematic comparison and a real migration playbook
Reference Architecture — running Native Federation v4 in a regulated enterprise

Article 2 is next: it takes the org restructuring covered above seriously and maps the actual package graph, so you know precisely which layer you're touching, and which promises it's making to the layers around it, before we go deep on any single one.

Next in this series: **Anatomy of the v4 Package Graph* — mapping Core, Adapters, Classic Runtime, and the Orchestrator as independently versioned layers with explicit contracts between them.*

Angular Schematics Deep Dive — Part 1: Understanding the Architecture

Sakthikumaran Navakumar — Mon, 09 Mar 2026 02:53:25 +0000

This is Part 1 of a 6-part series on Angular Schematics. The complete roadmap is listed at the end of this article. Future parts cover custom generators (ng generate), installation schematics (ng add), migration schematics (ng update), testing with Angular DevKit, and advanced patterns including Nx integration.

Every time you run ng generate component, ng add @angular/material, or ng update, something remarkably sophisticated is happening beneath the surface. Angular's CLI isn't simply copying template files — it is executing a structured, transactional, and fully testable code transformation pipeline. That pipeline is powered by Angular Schematics.

For many Angular developers, schematics remain a black box — something the framework uses internally, something Nx and Angular Material ship with, something you might glance at and walk away from. That's a missed opportunity. Understanding schematics is the difference between a developer who uses Angular tooling and one who extends it.

In this first article, we pull back the curtain completely. We'll examine the conceptual model, the runtime architecture, the four core abstractions, the virtual file system, and the execution pipeline that every schematic runs through. By the end, you'll have a precise mental model of how schematics work — which is the essential prerequisite for building your own.

What Exactly Is a Schematic?
How the Angular CLI Uses Schematics
Architecture Overview — The Four Pillars
The Schematic Execution Pipeline
Exploring the Built-in Schematics Collection
When to Create Custom Schematics
Summary & What's Next

What Exactly Is a Schematic?

At its core, a schematic is a pure function that describes file system transformations. It receives a representation of the file system as input and returns a description of how that file system should change — without directly touching disk until all transformations are validated and committed.

That definition contains three ideas worth unpacking carefully.

1. It's a pure function. Schematics follow functional programming principles. A schematic doesn't mutate the world directly. It receives state, produces a new description of state, and hands that description off to a runner.

2. It describes transformations — it doesn't execute them. Creating a file in a schematic isn't the same as calling fs.writeFileSync(). You're building a description of what should happen, giving the framework an opportunity to validate, preview, and batch everything before committing.

3. It operates on a virtual file system. The file system schematics work with is an in-memory representation. This is what makes dry-run mode, transactional rollbacks, and unit testing possible and practical.

💡 A useful mental model: Think of a schematic the way a database thinks of a transaction. You open a transaction (the virtual Tree), describe all your changes (Rules), and then either commit them all atomically or roll back entirely. No partial states, no corrupted workspaces.

How the Angular CLI Uses Schematics

Angular CLI commands map directly to schematics. When you run any of the following, you are invoking a schematic from a registered collection:

# Invokes the 'component' schematic from @schematics/angular
ng generate component my-feature

# Invokes the 'ng-add' schematic from @angular/material's package.json
ng add @angular/material

# Invokes migration schematics listed in the package's migrations.json
ng update @angular/core

This mapping is not magic — it's configuration. Every Angular library that participates in this ecosystem declares its schematics in package.json through two fields:

Field	Purpose	Example Value
`"schematics"`	Path to collection.json for ng generate / ng add	`"./schematics/collection.json"`
`"ng-update"`	Points to migrations.json for ng update	`{"migrations": "./migrations.json"}`

The collection.json acts as a manifest — a registry of all named schematics the package exposes, the TypeScript factory function for each, and the JSON schema that defines the schematic's options. The CLI reads this manifest, resolves the factory, and hands it to the DevKit runtime.

Architecture Overview — The Four Pillars

The Angular DevKit (@angular-devkit/schematics) is built around four foundational abstractions. Understanding each one precisely is the prerequisite for writing effective schematics.

1. Tree — The Virtual File System

The Tree is the representation of the workspace as the schematic sees it. It is an immutable snapshot combined with a staged layer of mutations that haven't been applied yet. When you call tree.create() or tree.overwrite(), you are adding entries to that staging layer — not touching disk.

import { Tree } from '@angular-devkit/schematics';

export function mySchematic(options: MyOptions) {
  return (tree: Tree) => {
    // READ — returns buffer or null (no I/O hits disk)
    const content = tree.read('angular.json');

    // WRITE — stages a change, does NOT write to disk
    tree.create('src/my-file.ts', 'export const x = 42;');

    // OVERWRITE — also staged, not committed yet
    tree.overwrite('src/app/app.module.ts', updatedContent);

    return tree; // return the mutated tree
  };
}

The Tree also exposes tree.exists(), tree.delete(), tree.rename(), and tree.getDir() for directory traversal. Everything is synchronous and backed by in-memory buffers unless you are reading a file that only exists on disk and hasn't been modified yet.

2. Rule — The Unit of Work

A Rule is the atomic unit of transformation in schematics. Its type signature is elegantly simple:

// From @angular-devkit/schematics internals
type Rule = (tree: Tree, context: SchematicContext)
  => Tree | Observable<Tree> | Rule | void;

Rules are composable. The DevKit provides chain() to compose multiple rules sequentially, branchAndMerge() to run rules on a branched copy of the Tree, and mergeWith() to merge a generated file source into the existing Tree. This composability is what makes schematics architecturally powerful — complex operations are built from simple, independently testable pieces.

import { Rule, chain, mergeWith, apply, url }
  from '@angular-devkit/schematics';

export function myFeature(options: Schema): Rule {
  return chain([
    addFilesFromTemplates(options),  // Rule 1
    updateAngularJson(options),      // Rule 2
    addImportToAppModule(options),   // Rule 3
  ]);
}

3. Source — Generating a New Tree

A Source is a factory that produces an entirely new, empty Tree from some origin — typically a directory of template files. The most commonly used Source is url(), which reads template files from a local directory. Sources are merged into the main Tree using mergeWith().

import { apply, url, applyTemplates, move, mergeWith }
  from '@angular-devkit/schematics';
import { strings } from '@angular-devkit/core';

const templateSource = apply(url('./files'), [
  applyTemplates({
    name: options.name,
    dasherize: strings.dasherize,
    classify: strings.classify,
  }),
  move(options.path),
]);

return mergeWith(templateSource);

4. SchematicContext — Runtime Information

The SchematicContext is passed alongside the Tree into every Rule. It provides access to the logger (use this instead of console.log), task scheduling (for running npm install after file generation), and the engine executing the schematic. It's the schematic's connection to the outside world.

import { SchematicContext, NodePackageInstallTask }
  from '@angular-devkit/schematics';

(tree: Tree, context: SchematicContext) => {
  context.logger.info('Installing dependencies...');

  // Schedule npm install to run AFTER all file mutations commit
  context.addTask(new NodePackageInstallTask());

  return tree;
};

The Schematic Execution Pipeline

With the four pillars understood, let's trace the full lifecycle of a schematic execution from CLI command to committed files.

CLI Command
───────────
ng generate component dashboard

     │
     ▼
CLI resolves collection
─────────────────────────
Reads package.json → "schematics": "./schematics/collection.json"
Reads collection.json → finds "component" entry → factory path

     │
     ▼
JSON Schema Validation
──────────────────────
Merges CLI flags + prompts against schema.json
Validates required fields, applies defaults
Prompts user for missing required options

     │
     ▼
Factory Function Invoked
─────────────────────────
schematic(options) → returns root Rule

     │
     ▼
Engine Creates Tree
────────────────────
Base layer  = current workspace on disk
Staging layer = empty (no mutations yet)

     │
     ▼
Rule Chain Executes
────────────────────
Rule 1: Generate files from templates → staged
Rule 2: Update angular.json            → staged
Rule 3: Add import to app.module.ts    → staged

     │
     ▼
Post-Rule Tasks Run
────────────────────
NodePackageInstallTask (if scheduled)
RunSchematicTask (chained schematics)

     │
     ▼
Commit (unless --dry-run)
──────────────────────────
Staging layer flushed to real disk
Console output: CREATE / UPDATE / DELETE logs

Exploring the Built-in Schematics Collection

The best way to learn schematic patterns is to read production-grade schematics. The entire @schematics/angular package is open source and worth studying carefully.

# Install to inspect locally
npm install @schematics/angular --save-dev

# Browse on GitHub:
# github.com/angular/angular-cli/tree/main/packages/schematics/angular

# List all available schematics in the built-in collection
ng generate --help

Inside @schematics/angular you'll find the implementation for every built-in generator: component, service, module, guard, pipe, directive, class, enum, interface, and application. Each one follows the same pattern: a schema.json defining options, an index.ts factory, and a files/ directory of templates.

Schematic	Location	Interesting Technique
`component`	`/component/`	Conditional template rendering based on `--standalone`
`module`	`/module/`	Routing module generation, lazy-load wiring
`guard`	`/guard/`	Multiple implementations based on `--implements` flag
`application`	`/application/`	Complete workspace scaffolding, cross-schematic calls

💡 Practical Tip: When learning schematics, clone the Angular CLI repo and read the component schematic in its entirety. It demonstrates conditional template inclusion, AST-based module updates, path normalization, and option defaults — all the patterns you'll use in production schematics.

When to Create Custom Schematics

Having established the technical foundation, the natural question is: when does writing a custom schematic become the right investment?

Repeated scaffolding patterns. If your team frequently creates a "feature module" that always includes a component, a service, a store, and a routing module — and that setup consistently takes 15 minutes of copy-pasting — you have a schematic waiting to be written. A single ng generate feature dashboard should handle it in under a second.

Enforcing architectural rules. Custom schematics are a powerful mechanism for ensuring generated code follows your team's conventions. Folder structures, naming patterns, required barrel files, mandatory test setups — all of these can be encoded into a schematic rather than documented in a wiki that no one reads.

Library installation complexity. If your internal UI library requires updating angular.json, modifying global styles, adding a provider to app.config.ts, and installing two peer dependencies — an ng add schematic automates all of that into a single, repeatable, idempotent operation.

Framework migrations. When you introduce a breaking change in your shared library — a renamed method, a restructured API, a changed import path — an ng update schematic can apply that migration automatically across every workspace that consumes your library. This is how Angular itself ships breaking changes responsibly.

🚦 The Decision Test: Ask yourself: "Would I describe this task in an onboarding doc?" If yes, the task is probably worth automating with a schematic. Documentation describes what humans should do manually. Schematics eliminate the need for the documentation entirely.

Summary & What's Next

We've covered significant ground. Here's what to take forward:

A schematic is a pure function that describes file system transformations on a virtual, in-memory representation of the workspace. The Angular CLI maps its core commands directly to schematics declared in package manifests. The DevKit runtime is built on four core abstractions:

Tree — virtual file system with a staging layer
Rule — atomic, composable unit of transformation
Source — template file origin that produces a new Tree
SchematicContext — runtime connection for logging and task scheduling

The virtual file system is the design decision that enables everything valuable about schematics: dry-run previews, atomic rollback, and millisecond-fast unit testing. The execution pipeline runs schema validation, factory invocation, rule chain execution, task scheduling, and a final atomic commit.

Understanding this architecture deeply is not just academic. It is the precise foundation upon which every practical schematic is built. In Part 2, we take this knowledge directly into the editor and build our first real custom generator — a feature module scaffolder that produces a complete, production-ready module structure in a single command.

Series Roadmap

Part	Topic	Status
Part 1	Understanding Angular Schematics — Architecture & Core Concepts	✅ You are here
Part 2	Creating Custom Generators with `ng generate`	🔜 Coming Soon
Part 3	Building Installation Schematics with `ng add`	🔜 Coming Soon
Part 4	Writing Migration Schematics with `ng update`	🔜 Coming Soon
Part 5	Testing Schematics with Angular DevKit	🔜 Coming Soon
Part 6	Advanced Patterns, Publishing & Monorepo Integration	🔜 Coming Soon

Previous Blogs:

https://dev.to/sakthicodes22/the-nx-cheatsheet-commands-for-daily-development-3h4k
https://dev.to/sakthicodes22/stop-the-spaghetti-enforcing-module-boundaries-in-an-nx-monorepo-2a24

Found this useful? Drop a ❤️ and share it with a teammate who would be intersted.

The Nx Cheatsheet — Commands for Daily Development

Sakthikumaran Navakumar — Mon, 02 Mar 2026 15:17:27 +0000

If you have just started working with Nx — or joined a team that uses it — the CLI can feel overwhelming at first. There are dozens of commands, flags, and concepts to absorb all at once.

This cheatsheet cuts through the noise. It covers the commands you will actually use every day, organised by workflow, explained plainly. Bookmark it, come back to it, share it with your team. Complete List of CLI commands can be found here.

📋 Table of Contents

What is Nx?
Creating a Workspace
Adding Plugins
Generating Projects and Code
Running and Serving Applications
Running Multiple Tasks
Filtering Projects with Patterns and Tags
Building Projects
The Affected Commands
Skipping and Managing the Cache
Running Tests
Linting and Formatting
Visualising the Dependency Graph
Workspace and Project Info
The Nx Daemon
Quick Reference Cheat Sheet

What is Nx?

Nx is an open-source build system and monorepo toolkit. It lets you manage all your applications and shared libraries in a single repository while giving you intelligent tooling to build, test, and serve them efficiently.

Three things make Nx stand out:

🧠 Smart task runner — understands your project dependency graph and only rebuilds what has actually changed
🏗️ Code generation — scaffolds apps, libraries, and components using best-practice templates
📊 Visualisation — interactive graph to see how all your projects connect

1. Creating a Workspace

Everything starts here. A workspace is the root container for all your applications and libraries.

# Create a new workspace interactively
npx create-nx-workspace@latest

# Create with a specific framework preset
# (react, angular, next, node, ts, empty)
npx create-nx-workspace@latest --preset=react

# Create a blank monorepo with a custom name
npx create-nx-workspace@latest --preset=empty --name=myorg

# Specify your preferred package manager (npm, yarn, pnpm)
npx create-nx-workspace@latest --packageManager=pnpm

# Add Nx to an already-existing project or monorepo
nx init

2. Adding Plugins

Nx is plugin-driven. Plugins provide the framework-specific generators and executors for React, Angular, Node, and more. The nx add command installs a plugin and automatically runs its initialisation generator in one step — no manual wiring required.

# Install the React plugin and auto-initialize it
nx add @nx/react

# Install the Angular plugin and wire it up automatically
nx add @nx/angular

3. Generating Projects and Code

Instead of manually creating folders and configuration files, let Nx do it for you. The nx generate (or nx g) command creates everything following best practices for your chosen framework.

# Generate a new application
nx g app <n>

# Generate a new shared library
nx g lib <n>

# Generate a component (framework-specific)
nx g component <n>

# Preview what will be generated WITHOUT writing any files
nx g app <n> --dry-run

4. Running and Serving Applications

Nx provides a consistent interface for running your projects regardless of which framework or tooling is underneath. nx serve myapp is shorthand for nx run myapp:serve — both do the same thing.

# Start a local development server
nx serve <project>

# Run any defined target on a project
nx run <project>:<target>

# Run a target with a specific configuration (e.g. production, staging)
nx run <project>:<target>:<configuration>

5. Running Multiple Tasks

As your monorepo grows, you need to run operations across multiple projects at once. nx run-many fans out work across your workspace in parallel. The default parallelism is 3 — increase it based on your machine's capacity.

# Run multiple targets across ALL projects in one command
nx run-many -t build test lint

# Run multiple targets on specific named projects only
nx run-many -t build test lint -p app1 app2

# Run tasks with a concurrency limit
nx run-many -t build --parallel=5

# Run with the interactive Terminal UI (new in Nx v22)
nx run-many -t build --outputStyle=tui

6. Filtering Projects with Patterns and Tags

Instead of listing every project name manually, use glob patterns and Nx project tags to target exactly the right set of projects. Tags are labels you assign to projects in their config — for example scope:frontend or type:ui.

# Run only projects tagged with scope:frontend
nx run-many -t build --projects='tag:scope:frontend'

# Run only projects whose names end with -app
nx run-many -t build --projects='*-app'

# Mix explicit names and glob patterns
nx run-many -t test --projects='app1,app2,shared-*'

# Run on all projects, EXCLUDING e2e projects
nx run-many -t lint --exclude='*-e2e'

7. Building Projects

Building compiles your source code and produces deployment-ready artifacts. The command is the same regardless of whether you use Webpack, Vite, or esbuild underneath.

# Build a specific project
nx build <project>

# Build using the production configuration (optimised, minified)
nx build <project> --configuration=production

# Build all projects in the workspace
nx run-many -t build

8. The Affected Commands — Nx's Superpower

This is the feature that makes Nx genuinely transformative. Instead of rebuilding and retesting everything on every commit, Nx analyses your dependency graph and figures out exactly which projects are affected by your changes — and only runs tasks for those.

If you change a utility library, Nx identifies every app and library that depends on it and runs the target for all of them. Everything else is skipped. On a large monorepo, this can reduce CI time significantly.

# Build only projects affected by recent changes
nx affected -t build

# Test only affected projects
nx affected -t test

# Lint only affected projects
nx affected -t lint

# Run multiple targets on affected projects in one command
nx affected -t build test lint

# Determine affected projects relative to a specific branch/commit range
nx affected --base=main --head=HEAD

9. Skipping and Managing the Cache

Nx caches the results of every task. If nothing has changed since the last run, Nx replays the cached result in milliseconds. There are times, however, when you need to bypass the cache — debugging a flaky test, verifying a fix actually works, or clearing stale output.

Refer here for How caching works

# Run a build bypassing the local cache entirely
nx build <project> --skipNxCache

# Skip cache for all projects in run-many
nx run-many -t build --skipNxCache

# Skip cache on all affected test runs
nx affected -t test --skipNxCache

# Clear the entire local cache AND daemon state
nx reset

# Clear ONLY the task cache, leave the daemon running
nx reset --only-cache

# Restart ONLY the daemon, leave the cache intact
nx reset --only-daemon

10. Running Tests

Whether your projects use Jest, Vitest, Playwright, or Cypress, nx test and nx e2e provide a consistent interface. Combine with affected and run-many for full-scale coverage.

# Run unit tests for a specific project
nx test <project>

# Run end-to-end tests for a project
nx e2e <project>

# Run unit tests only for affected projects
nx affected -t test

# Run unit tests across ALL projects
nx run-many -t test

11. Linting and Formatting

Keeping code quality consistent across a monorepo is hard without tooling. Nx gives every project its own lint target and provides workspace-level format commands powered by Prettier.

# Lint a specific project
nx lint <project>

# Lint only the projects affected by recent changes
nx affected -t lint

# Auto-format ALL files in the workspace using Prettier
nx format:write

# Check formatting across the workspace WITHOUT writing (perfect for CI)
nx format:check

12. Visualising the Dependency Graph

At any point you can visualise the entire architecture of your monorepo as an interactive browser-based graph. This is invaluable for onboarding new team members, auditing architecture, and understanding the blast radius of a change.

# Open the interactive dependency graph in the browser
nx graph

# Show only the subgraph of a specific project and its dependencies
nx graph --focus=<project>

# Print the project graph as JSON to the terminal
nx graph --print

# Export the full graph to a JSON file
nx graph --file=output.json

13. Workspace and Project Info

As your workspace grows, you need reliable ways to explore it. The nx show, nx list, and nx report commands answer the everyday questions: what exists, what is affected, what plugins are installed.

# List ALL projects in the workspace
nx show projects

# List only the projects affected by recent changes
# (modern replacement for the deprecated nx affected:apps/libs)
nx show projects --affected

# List all projects that have a specific target defined
nx show projects --with-target serve

# Show full configuration details of a specific project
nx show project <n>

# Open a rich browser view of a project's fully resolved configuration
nx show project <n> --web

# List all installed Nx plugins in the workspace
nx list

# List all generators and executors provided by a specific plugin
nx list <plugin>

# Print all installed Nx and plugin versions (essential for debugging)
nx report

14. The Nx Daemon

The Nx Daemon is a background process that keeps your workspace's project graph in memory. Without it, every command has to re-read and re-parse your entire workspace from scratch — noticeable latency in large monorepos. In most cases it starts and stops automatically. These commands give you manual control when needed.

# Manually start the Nx daemon
nx daemon --start

# Stop the Nx daemon
nx daemon --stop

⚡ Quick Reference Cheat Sheet

🏗️ Workspace Setup

Command	What it does
`npx create-nx-workspace@latest`	Create a new workspace
`nx init`	Add Nx to an existing project
`nx add @nx/react`	Add and initialize a plugin

🔧 Generate Code

Command	What it does
`nx g app <n>`	New application
`nx g lib <n>`	New shared library
`nx g component <n>`	New component
`nx g app <n> --dry-run`	Preview generation without writing files

▶️ Run Tasks

Command	What it does
`nx serve <project>`	Start dev server
`nx build <project>`	Build a project
`nx test <project>`	Run unit tests
`nx e2e <project>`	Run e2e tests
`nx lint <project>`	Lint a project

🚀 Scale Across Projects

Command	What it does
`nx run-many -t build test lint`	Run multiple targets across all projects
`nx run-many -t build --parallel=5`	Run with concurrency control
`nx run-many -t build --projects='*-app'`	Target projects by glob pattern
`nx run-many -t build --projects='tag:scope:frontend'`	Target projects by tag
`nx run-many -t lint --exclude='*-e2e'`	Exclude projects by pattern
`nx affected -t build test lint`	Only run what is affected by your changes
`nx affected --base=main --head=HEAD`	Affected in a PR commit range

🗄️ Cache Management

Command	What it does
`nx build <project> --skipNxCache`	Bypass cache for one task
`nx reset --only-cache`	Clear task cache only
`nx reset --only-daemon`	Restart daemon only
`nx reset`	Full reset — cache + daemon

🔍 Explore & Debug

Command	What it does
`nx graph`	Open interactive dependency graph
`nx graph --focus=<project>`	Focus graph on one project
`nx show projects --affected`	List affected projects
`nx show project <n> --web`	Inspect full project config in browser
`nx report`	Check all installed plugin versions
`nx format:check`	Check formatting (great for CI)
`nx format:write`	Auto-format the entire workspace

Useful Links

📖 Official Nx Documentation
🔧 Nx CLI Reference (v22)

Found this useful? Drop a ❤️ and share it with a teammate who is just getting started with Nx.

Stop the Spaghetti: Enforcing Module Boundaries in an Nx Monorepo

Sakthikumaran Navakumar — Sat, 28 Feb 2026 14:44:59 +0000

Enforcing Module Boundaries in an Nx Monorepo

It starts with good intentions. Your team decides to adopt a monorepo. You scaffold your workspace, create a handful of libraries, and for the first few sprints everything feels clean and purposeful. Then the deadlines hit.

A developer needs a formatting utility from the payments module — so they reach in and import it directly. Another engineer needs a component from the loans feature for a quick prototype in the accounts section. Someone else, pressed for time, imports a service three layers deep from another domain's internals. Nobody reviews it too carefully. The CI pipeline is green. Ship it.

Six months later, your dependency graph looks like a bowl of spaghetti. The payments domain knows about accounts. The accounts feature imports from loans. Shared utilities carry domain-specific logic. Nobody can confidently change anything without triggering a cascade of broken imports across the workspace. Your architecture diagram, proudly mounted on the team's Confluence page, bears no resemblance to what the codebase actually does.
This is not a discipline problem. It is a tooling problem. And Nx solves it elegantly.

Why Module Boundaries Matter: The Architectural Case

Before we look at the tooling, it is worth understanding why boundary enforcement is not just a nice-to-have but an architectural necessity in any sufficiently large codebase.

Implicit Coupling Is the Silent Killer

In a monorepo without enforced boundaries, any library can import from any other library. Technically, there is nothing stopping a UI component from reaching directly into a data-access service, or a feature module from importing internal implementation details from a completely unrelated domain. These imports create implicit coupling — undocumented, invisible dependencies that accumulate quietly until refactoring becomes genuinely dangerous.

Social Enforcement Does Not Scale

With a team of three engineers and ten libraries, you can maintain architectural discipline through code review and shared understanding. With a team of fifteen engineers, forty libraries, and three concurrent feature tracks, you cannot. The cognitive overhead of manually auditing import paths in code review is enormous, the feedback loop is slow, and violations slip through. You need the tooling to carry the architectural intent forward, independent of team size, experience level, or deadline pressure.

The Architecture Diagram Should Match the Import Graph

This is the principle that underpins everything. If your architecture diagram shows that the payments domain is isolated from the loans domain, then your import graph should reflect exactly that. Nx module boundary enforcement is the mechanism that keeps these two things in sync — automatically, continuously, and without relying on human vigilance.

The Nx Mental Model: Tags and Dependency Constraints

Nx enforces boundaries through a tag-based system. Each library in your workspace is assigned one or more tags via its project.json file, and your ESLint configuration defines rules that govern which tags are allowed to depend on which other tags.

Tags typically carry two dimensions of information: scope and type.

Scope answers the question: which domain or vertical does this library belong to? In a banking application, you might have scopes like scope:payments, scope:loans, scope:accounts, scope:kyc (Know Your Customer), and scope:shared.

Type answers the question: what architectural layer or role does this library play? Rather than the generic feature/ui/data-access/util convention, a more expressive and flexible approach uses tags like type:app, type:lib, type:shared, and type:e2e. This maps more naturally to how libraries actually behave in large-scale production workspaces and gives you coarser, more durable rules.

Here is how tags are applied in a library's project.json:

//apps/banking-portal-e2e/project.json
{
  "name": "banking-portal-e2e",
  "projectType": "application",
  "tags": ["scope:banking-portal", "type:e2e"]
}

Once your libraries are tagged, the ESLint rule @nx/enforce-module-boundaries becomes the enforcement engine.

The Sample Project Structure

Before diving into the ESLint configuration, here is the workspace structure we will be working with throughout this article. This represents a simplified but realistic banking platform monorepo.

banking-workspace/
├── apps/
│   ├── banking-portal/       # Customer-facing web app
│   │   └── project.json      # tags: scope:banking-portal, type:app
│   ├── banking-portal-e2e/   # E2E tests for banking-portal
│   │   └── project.json      # tags: scope:banking-portal, type:e2e
│   ├── admin-dashboard/      # Internal ops/admin app
│       └── project.json      # tags: scope:admin, type:app  
├── libs/
│   ├── payments/
│   │   ├── feature-transfer/ # tags: scope:payments, type:lib
│   │   ├── feature-transaction-history/ # tags: scope:payments, type:lib
│   │   └── data-access/      # tags: scope:payments, type:lib
│   ├── loans/
│   │   ├── feature-apply/    # tags: scope:loans, type:lib
│   │   ├── feature-repayment/# tags: scope:loans, type:lib
│   │   └── data-access/      # tags: scope:loans, type:lib
│   ├── accounts/
│   │   ├── feature-dashboard/# tags: scope:accounts, type:lib
│   │   ├── feature-settings/ # tags: scope:accounts, type:lib
│   │   └── data-access/      # tags: scope:accounts, type:lib
│   ├── kyc/
│   │   ├── feature-onboarding/# tags: scope:kyc, type:lib
│   │   └── data-access/       # tags: scope:kyc, type:lib
│   └── shared/
│       ├── ui-design-system/  # tags: scope:shared, type:shared
│       ├── ui-forms/          # tags: scope:shared, type:shared
│       ├── util-formatters/   # tags: scope:shared, type:shared
│       ├── util-validators/   # tags: scope:shared, type:shared
│       └── data-access-http/  # tags: scope:shared, type:shared

Every domain (payments, loans, accounts, kyc) is a self-contained vertical. The shared scope holds anything that is genuinely cross-cutting. Apps consume libs. Libs do not reach into other domain's libs unless explicitly permitted. E2E projects only test — they never become a source of shared logic.

Enforcing Boundaries with the Nx ESLint Plugin

With the project structure established, let us look at the ESLint configuration that encodes these architectural rules. All of this lives in your root .eslintrc.json.

{
  "root": true,
  "plugins": ["@nx"],
  "overrides": [
    {
      "files": ["*.ts", "*.tsx", "*.js", "*.jsx"],
      "rules": {
        "@nx/enforce-module-boundaries": [
          "error",
          {
            "enforceBuildableLibDependency": true,
            "allowCircularSelfDependency": true,
            "banTransitiveDependencies": true,
            "depConstraints": [

              {
                "sourceTag": "type:app",
                "onlyDependOnLibsWithTags": ["type:lib", "type:shared"]
              },

              {
                "sourceTag": "type:lib",
                "onlyDependOnLibsWithTags": ["type:lib", "type:shared"]
              },

              {
                "sourceTag": "type:shared",
                "onlyDependOnLibsWithTags": ["type:shared"]
              },

              {
                "sourceTag": "type:e2e",
                "onlyDependOnLibsWithTags": ["type:shared"]
              },

              {
                "sourceTag": "scope:payments",
                "onlyDependOnLibsWithTags": ["scope:payments", "scope:shared"]
              },
              {
                "sourceTag": "scope:loans",
                "onlyDependOnLibsWithTags": ["scope:loans", "scope:shared"]
              },
              {
                "sourceTag": "scope:accounts",
                "onlyDependOnLibsWithTags": ["scope:accounts", "scope:shared"]
              },
              {
                "sourceTag": "scope:kyc",
                "onlyDependOnLibsWithTags": ["scope:kyc", "scope:shared"]
              },
              {
                "sourceTag": "scope:shared",
                "onlyDependOnLibsWithTags": ["scope:shared"]
              }

            ]
          }
        ]
      }
    }
  ]
}

This configuration encodes six architectural decisions simultaneously:

Apps can consume domain libs and shared libs — but never other apps
Domain libs can consume other libs within their own scope and anything in shared — but never reach across domain boundaries
Shared libs are the foundation layer — they are self-contained and import nothing outside their own scope
E2E projects can reference shared utilities if needed, but are otherwise isolated from application and domain logic
banTransitiveDependencies ensures that if lib A depends on lib B which depends on lib C, lib A cannot import from lib C directly — it must go through lib B's public API
enforceBuildableLibDependencyCheck ensures that if you enable buildable libs, your dependency declarations stay honest

Advanced Tag Expressions: !, *, and Combining Constraints

One of the most underused and underappreciated features of the @nx/enforce-module-boundaries rule is its support for tag expression operators. Beyond simple string matching, the rule supports negation, wildcards, and compound logic that lets you write precise, expressive constraints.

The Wildcard Operator: *

The wildcard * matches any tag. This is useful when you want to say "this library can import from literally anything" — which you should use sparingly, but it has legitimate use cases for certain shell or orchestration libraries.

{
  "sourceTag": "type:app",
  "onlyDependOnLibsWithTags": ["*"]
}

More practically, wildcards shine when used within a tag expression for partial matching. For example, if you want to allow a shared utility to depend on any shared library regardless of a sub-classification:

json
{
  "sourceTag": "scope:shared",
  "onlyDependOnLibsWithTags": ["scope:shared", "*:shared"]
}

You can also use ! directly within the onlyDependOnLibsWithTags array to say "must have this tag and must not have that tag simultaneously":

json{
  "sourceTag": "scope:accounts",
  "onlyDependOnLibsWithTags": ["scope:accounts", "scope:shared", "!type:e2e"]
}

This reads as: "accounts-scoped libraries may only depend on libraries that are tagged scope:accounts or scope:shared, and in all cases, those libraries must not be tagged type:e2e." This is particularly useful when your shared scope contains a mix of test utilities and production utilities that you want to distinguish at the dependency constraint level.

Violations in Action: What This Looks Like in Your IDE
Let us see what happens when a developer violates one of these rules. This is arguably the most important section of the article because it shows the tangible developer experience of boundary enforcement.
typescript// libs/payments/feature-transfer/src/lib/transfer.component.ts


// ✅ ALLOWED — payments lib importing from its own domain
import { PaymentsApiService } from '@banking/payments/data-access';

// ✅ ALLOWED — payments lib importing from shared scope
import { CurrencyFormatterPipe } from '@banking/shared/util-formatters';
import { ButtonComponent } from '@banking/shared/ui-design-system';

// ❌ VIOLATION — crossing domain boundaries
import { LoanEligibilityService } from '@banking/loans/data-access';
// ESLint Error: "A project tagged with 'scope:payments' can only depend on 
// libs tagged with 'scope:payments' or 'scope:shared'"

// ❌ VIOLATION — lib importing from an app
import { AppConfig } from '@banking/banking-portal';
// ESLint Error: "A project tagged with 'type:lib' cannot depend on 
// libs tagged with 'type:app'"

// ❌ VIOLATION — reaching into e2e project
import { MockApiInterceptor } from '@banking/banking-portal-e2e';
// ESLint Error: "Imports of e2e projects are not permitted"

These errors surface in real time in VS Code (with the ESLint extension installed).

The Architectural Payoff

Once module boundaries are in place and running in CI, the benefits compound over time in ways that go well beyond code organization.

Your architecture becomes self-documenting. A new engineer joining the banking platform team can read the ESLint configuration and understand the entire domain structure and dependency rules in under five minutes. The rules tell the same story as the architecture diagram — because they are the architecture diagram, expressed as code.
Code reviews become faster and more focused. Reviewers no longer need to manually audit import paths or ask questions like "should payments really know about loans?" The linter has already answered that question before the pull request was opened. Reviews can focus entirely on logic, correctness, and intent.
Refactoring becomes safe. Because every library exposes only what its index.ts exports, and because boundaries prevent cross-domain imports, you can refactor a library's internals with surgical confidence. The blast radius of any change is bounded by the public API surface.
Teams can work in parallel without stepping on each other. When domain boundaries are enforced, the payments team and the loans team genuinely cannot create accidental dependencies between their work. Conway's Law works in your favour: the organizational structure is mirrored by — and protected by — the module boundary rules.
The architecture survives team turnover. Senior engineers who understand the original design decisions eventually leave. Without tooling, their architectural intent leaves with them. With boundary enforcement, the decisions are encoded in the linting configuration and outlive any individual contributor.

The companion repository for this article, including the full workspace structure, ESLint configuration, sample library implementations, and intentional violations with their error output, is available at github. Clone it, break the rules, and watch the linter push back.

github: https://github.com/sakthikumaran22/nx-module-boundaries-demo

Reference:

DEV Community: Sakthikumaran Navakumar

The Orchestrator - How Native Federation v4 Decides What Loads (and What Changed in 4.8.0)

How you use it

How it works, in four steps

Decision 1: choosing the version

Same example, different result

Decision 2: one build per package (4.8.0)

Before 4.8.0: borrowing missing parts

In 4.8.0: one build serves each package

The trade-off

What to do now

Remotes added later, and caching

Trade-offs to know

Series roadmap

Further reading

The Classic (v3) Runtime - What It Got Right, and Where It Hit Its Limit

How it works, in four steps

What versions can it resolve? Only exact matches

Seeing it in the files

Your lockfile decides, not your package.json

Remotes the host doesn't know up front

Your federation.config settings don't apply here

Why duplicate copies hurt

What it got right

Where it hit its limit

Living with it until you migrate

What Part 5 answers

Series roadmap

Further reading

Build-Time, End to End - From federation.config to remoteEntry.json

A few terms first

Normal build vs. federated build

The input: federation.config.mjs

Choosing what to share

The settings on each library

skip: leaving a library out of sharing

includeSecondaries and keepAll: the sub-paths

How the build decides what's "used"

What happens when you build

The output: remoteEntry.json and importmap.json

remoteEntry.json: what this app offers and needs

importmap.json: this app's own view

Static and dynamic remotes

Where version resolution fits

Key takeaways

Series roadmap

Further reading

Anatomy of the v4 Package Graph - Core, Adapters, Runtime, and Orchestrator

A few terms first

From one plugin to four repositories

The four layers

Core: runs at build time, and only at build time

Adapters: connect a specific tool to Core

Classic Runtime: the original browser loader

Orchestrator: the new browser loader

The one contract that connects everything

Quick reference: which package does what

Check your own project

Series roadmap

References

Native Federation - Deep Dive - Part 1/8 - The Mental Model, Why Native Federation Exists and What Changed in v4

The compromise nobody talked about

What "browser-native" actually buys you

Why this matters more in v4 than it did in v3

Series Roadmap

Angular Schematics Deep Dive — Part 1: Understanding the Architecture

Table of Contents

What Exactly Is a Schematic?

How the Angular CLI Uses Schematics

Architecture Overview — The Four Pillars

1. Tree — The Virtual File System

2. Rule — The Unit of Work

3. Source — Generating a New Tree

4. SchematicContext — Runtime Information

The Schematic Execution Pipeline

Exploring the Built-in Schematics Collection

When to Create Custom Schematics

Summary & What's Next

Series Roadmap

Previous Blogs: