Angular 21 with native federation crash

[kukjevov]

With what library do you have an issue?

native-federation

Reproduction of the bug/regression with instructions

When i am trying to use native federation with angular cli ng serve crashes (not all the time) and exits with code -1073740940 (Process exited with code 3221226356)

Reproduction steps

git clone https://github.com/kukjevov/native-federation-bug.git
cd native-federation-bug
npm install
npm start or cd main && npx ng serve

Or there are already profiles for vscode for debugging Launch Ng Serve or Launch Lerna Start

Expected behavior

This should work

Versions of Native/Module Federation, Angular, Node, Browser, and operating system

Native Federation: 21.0.3
Angular: 21.0.5
Angular CLI: 21.0.3
Node: 24.12.0
NPM: 11.6.2
Browser: not important (build fails, if build succeed app works)
Operation System: Windows 11

Other information

No response

I would be willing to submit a PR to fix this issue

• Yes
• No

[Aukevanoost]

Hi @kukjevov

Cheers for the reproducable example, I took some time to debug but haven't found what's been causing the issue yet, it's definitely happening during the compilation of the exposed module in the Angular compiler. Now unfortunately I wont have time to debug the whole application given the amount of packages, web-workers and extra modifications you did to the repo any time soon. But I can give you this.

The crash:
During the serveWithVite function in the devserver builder, vite is imported dynamically (and vite imports some internal chunks), the chunk below fails as soon as it is imported:

node_modules/vite/dist/node/chunks/config.js

at the line:

import { parseAst, parseAstAsync } from "rollup/parseAst";

Now I figured out where the crash is happening and it's because rollup tries to access corrupted memory here:

const { platform, arch, report } = require('node:process');
return report.getReport().header.osName.startsWith('MINGW32_NT');

file: https://github.com/rollup/rollup/blob/c5f3e1d3162ccb36e18704138c21457a084ef358/native.js#L15C1-L15C68

A little bit of googling around tells me that the Report returns the current state of the node process (which is probably broken). I still don't know where the node process get's corrupted.

So what's crazy about this is that the getReport() tries to access the node diagnostics report which is completely unusable due to the so called corruption. 

I am 99% sure the corruption happens in the createCompilerPlugin from the angular-cli. Our native-federation builder runs in 3 steps:

• Build shared-mappings and exposed
• Build external libraries
• build/serve angular

Where is the corruption happening:
build-for-federation -> bundle-exposed-and-mappings -> angular-esbuild-adapter -> compiler-plugin. I think for you it's because one of the externals is not correctly imported or compiled. Or there is a webworker/process/plugin running during the compilation. It's not a timing issue since the curious thing here is that it's happening more often when the externals are already compiled and cached. So that process isn't even running (step 2). You can verify this by adding the verbose option at the "esbuild" builder in your angular.json.

So where to next?
I tried to remove some services and processes but you can try the following:

• Remove extra polyfill stuff like modernizr
• Enable the ignoreUnusedDeps feature at your federation.config.json, you will have to create an extra main/src/main.ts file with the line `import "../app/main.browser"; in it.
• See if the service-workers are the issue, I generally recommend not to provide webworkers in your micro frontends due to their complex nature, it's best to communicate to them through the host or something, this shouldn't be a micro frontend concern.
• I saw that you had a lot of custom angular packages (@anglr for example), maybe one of those packages could be the issue if it interferes with node or the node workers?
• See if the issue is a tsconfig configuration, since your federation.config.js is processed as esm? usually it's as cjs.

So basically, strip down your application and see what's causing this, and if you find something interesting I'd love to know!

Cheers and apologies in advance. I might be able to look at it later but I'm not sure it'll be this year.

[kukjevov]

Thx for answer and for looking into problem. Curious thing is that as you wrote "curious thing here is that it's happening more often when the externals are already compiled and cached", because this is what i also observed. And another thing that i observed is that, if i run compilation with debugging it will never crash without that caching enabled. So for me now it is working and i can work with this, but if i will have time i will try to strip down project one package at time and try to find out where is the problem. Still dont understand why it happens only during serve and never within build. This does not hurry so its not a problem if it will be solved later and i have "workaround" for now.

[Aukevanoost]

Right, that is an interesting observation indeed! So that would mean that maybe, native federation isnt able to access the cached modules? What I observed was that native federation creates a new node_modules folder in the main folder where it stores the cached files, maybe the issue is somewhere there? This is probably nothing but worth investigating.

It's only happening with serve because that's where the heap corruption error is thrown. It happens in the vite package which isn't in the build (since that's esbuild only). Vite is using rollup which is trying to access the corrupted memory during the import and 'getReport' function.