DEV Community: Sakthikumaran Navakumar

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

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:

The Nx Cheatsheet — Commands for Daily Development

📋 Table of Contents

What is Nx?

1. Creating a Workspace

2. Adding Plugins

3. Generating Projects and Code

4. Running and Serving Applications

5. Running Multiple Tasks

6. Filtering Projects with Patterns and Tags

7. Building Projects

8. The Affected Commands — Nx's Superpower

9. Skipping and Managing the Cache

10. Running Tests

11. Linting and Formatting

12. Visualising the Dependency Graph

13. Workspace and Project Info

14. The Nx Daemon

⚡ Quick Reference Cheat Sheet

🏗️ Workspace Setup

🔧 Generate Code

▶️ Run Tasks

🚀 Scale Across Projects

🗄️ Cache Management

🔍 Explore & Debug

Useful Links

Stop the Spaghetti: Enforcing Module Boundaries in an Nx Monorepo

Enforcing Module Boundaries in an Nx Monorepo

Why Module Boundaries Matter: The Architectural Case