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.

[kukjevov]

Hi @Aukevanoost, have you had any time to look into it, i am trying to debug it, but its quite complicated. What i have found out is that if you remove all 'sharedDepdencies' it still crashes.

[kukjevov]

Hmm another interesting thing, i have changed compilation of angular to "not parallel" and also sass compilation max number of threads to 1 and it is not crashing anymore. Maybe i am mistaken but so far it looks like a problem with sass parallel compilation.

[kukjevov]

Ok its definitely connected with sass compilation, when i set this line https://github.com/angular/angular-cli/blob/main/packages/angular/build/src/tools/sass/sass-service.ts#L97 to 1 it is working everytime, i have tried 10 tries without failure, if i increase number of threads it happens more often, if i set it to 8 it happens all time.

[Aukevanoost]

Hi @kukjevov!
No haven't found the time yet but thanks for this! I'll try to have a look at it ASAP. Maybe the worker pool is not being closed correctly.

[Aukevanoost]

Hi @kukjevov

Sorry I haven't had much time yet, but I think this is an Angular issue. This is what I know so far:

Chain of calls (in @angular/build):

• compiler-plugin.ts
• component-stylesheets.ts
• bundle-options set's up the sass plugin.
• sass-loanguage.ts Calls the compileString method from sass-language.ts
• sass-language Spins up the workerpool

Now I already tried to dispose the stylesheetBundler in the compiler-plugin but without success:

      build.onDispose(() => {
        sharedTSCompilationState?.dispose();
        void compilation.close?.();
        void javascriptTransformer.close();
        void cacheStore?.close();
        void stylesheetBundler.dispose();
      });

What we can see is that the sass-language.ts has a shutdownWorkerPool which is used in the build-action.ts but nowhere else! this is curious since the build-action is not used in our builder (yet?) but then again it's a full blown Angular builder so it might not be what we need. It's worth looking into though.

Final remarks, we are loading a loadPostCssConfiguration which we might be able to leverage to close the workerpool? If that's even the issue. We do that here in the angular-adapter. The biggest problem is that we're not allowed to swap the ComponentStylesheetBundler since it's all hardcoded in their private.ts entry barrel file. Although the options we can provide does have a sass prop. I don't think it's very useful though.

Anyway, this is all the time I had for this so far. I hope I can continue soon on this but feel free to have a look around yourself too!