Pending chunks for a long time

[ladler1]

I observe that the rebuild is fast compared to v3 but the loading of chunks can take up to 10 seconds in which they are in pending state:

[Aukevanoost]

Hi @ladler1 good point.

There are multiple ways to fix this, v4 came with some goodies:

• disable chunks in your angular.json: https://github.com/Aukevanoost/native-federation-examples-ng/blob/5685f7faa99071dc442428b7b6fe1092941d8596/angular.json#L21
• Build your dependencies as isolated packages, this will take a bit more build time but ensures isolation. You can use the build: package prop: https://github.com/Aukevanoost/native-federation-examples-ng/blob/5685f7faa99071dc442428b7b6fe1092941d8596/projects/mfe1/federation.config.js#L11
• Use the "ignoreUnusedDeps" feature! it's gotten a lot better over time: https://github.com/Aukevanoost/native-federation-examples-ng/blob/5685f7faa99071dc442428b7b6fe1092941d8596/projects/mfe1/federation.config.js#L23

Let me know if it helps!

[ladler1]

Thank you very much for your support I'm currently investigating if something changes when setting the options you provided.

• ignoreUnusedDeps was allready activated in my federation.config.
• the build: package option seems to make no difference the chunks are still in loading state for a longer time.
• when disabling chunks in angular.json I get an error:

signal.ts:112 ERROR RuntimeError: NG0200: Circular dependency detected for _HttpClient. Source: _AppEssentialModule. Path: _AngBasicCmsControllerService -> _HttpClient. Find more at https://v20.angular.dev/errors/NG0200
at createRuntimeError (injector_compatibility.ts:63:16)
at cyclicDependencyError (errors_di.ts:146:1)
at R3Injector.hydrate (r3_injector.ts:652:23)
at R3Injector.get (r3_injector.ts:496:30)
at R3Injector.retrieve (r3_injector.ts:351:23)
at injectInjectorOnly (injector_compatibility.ts:357:12)
at ɵɵinject (injector_compatibility.ts:386:33)
at inject2 (array_utils.ts:19:17)

adding a service with providedIn: 'root' with inject(HttpClient) in your demo application (https://github.com/Aukevanoost/native-federation-examples-ng/blob/5685f7faa99071dc442428b7b6fe1092941d8596/angular.json#L21):
@Injectable({ providedIn: 'root' }) export class MainService { private http = inject(HttpClient); getData() {

shows in the browser console an error regarding httpClient too:

njector_compatibility.ts:33 Uncaught ɵNotFound: NG0201: No provider found for XhrFactory. Path: _MainService -> _HttpClient -> _HttpHandler -> _HttpInterceptorHandler -> _HttpBackend -> _HttpXhrBackend -> XhrFactory. Find more at https://v21.angular.dev/errors/NG0201
at createRuntimeError (injector_compatibility.ts:33:14)
at NullInjector.get (provider_collection.ts:204:22)
at R3Injector.get (r3_injector.ts:483:20)
at R3Injector.get (r3_injector.ts:483:20)
at R3Injector.retrieve (r3_injector.ts:339:71)
at injectInjectorOnly (injector_compatibility.ts:339:16)
at Module.ɵɵinject (injector_compatibility.ts:353:9)
at Object.HttpXhrBackend_Factory [as factory] (_module-chunk.mjs:1234:17)
at r3_injector.ts:652:10
at runInInjectorProfilerContext (def_getters.ts:19:1)

when setting "chunks": { "enable": true in your demo application the error is gone

I also tried a minimal share example which seems to be necessary for my application:
shared: {
...share({
// test minimal share
'@angular/core': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
'@angular/common': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
'@angular/common/http': { singleton: true, strictVersion: true, requiredVersion: 'auto', includeSecondaries: false, build: 'package' },
// '@angular/platform-browser': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
// '@angular/platform-browser-dynamic': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
'@angular/router': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
// '@angular/forms': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
'@jsverse/transloco': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
'@angular/service-worker': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
'@angular/common/locales/de': { packageInfo: { entryPoint: '@angular/common/locales/de', esm: true, build: 'package' } },
'@angular/common/locales/en': { packageInfo: { entryPoint: '@angular/common/locales/en', esm: true, build: 'package' } },
'@angular/common/locales/fr': { packageInfo: { entryPoint: '@angular/common/locales/fr', esm: true, build: 'package' } },
'@angular/common/locales/ar': { packageInfo: { entryPoint: '@angular/common/locales/ar', esm: true, build: 'package' } },
'@angular/common/locales/id': { packageInfo: { entryPoint: '@angular/common/locales/id', esm: true, build: 'package' } },
'@angular/common/locales/zh': { packageInfo: { entryPoint: '@angular/common/locales/zh', esm: true, build: 'package' } },
'@angular/common/locales/zh-Hans': { packageInfo: { entryPoint: '@angular/common/locales/zh-Hans', esm: true, build: 'package' } },
'@angular/common/locales/zh-Hant': { packageInfo: { entryPoint: '@angular/common/locales/zh-Hant', esm: true, build: 'package' } },
'@angular/common/locales/ja': { packageInfo: { entryPoint: '@angular/common/locales/ja', esm: true, build: 'package' } },
'@angular/common/locales/ms': { packageInfo: { entryPoint: '@angular/common/locales/ms', esm: true, build: 'package' } },
}),
},

but this brought no improvement the output is allways the same:

Application bundle generation complete. [1.279 seconds] - 2026-03-21T06:46:52.353Z

Page reload sent to client(s).

So this seems to be fast but after this log the chunks are in pending state for about 10 seconds

[Aukevanoost]

Hi @ladler1

I did some digging and, I think the reason that you're chunks are "pending" for so long is (as you might have guessed) that native-federation is overwelming your browser with 100 chunk downloads. By default a browser can download ~6 xhr requests at the same time (don't quote me on this). So we should limit the amount of files downloaded and I baked some options in the newest native-federation release candidate:

1. Let's minimize the amount of chunks you're using. I reproduced the error you mentioned when setting chunks: {enabled: false} and the reason for this (from what I could see) is that @angular/common and @angular/common are already partially compiled in chunks, so they expect to be served in chunks. Therefore I made a bit more fine grained control regarding chunks. Where you can enable/disable chunking in the federation.config.js, and override it per external. I know this might sound a bit fuzzy and abstract so have a look at the new federation.config.js setup in this example!

2. Let's minimize the amount of dependencies you're using. You mentioned you're using these externals:

shared: {
  ...share({
    // test minimal share
    '@angular/core': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
    '@angular/common': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
    '@angular/common/http': { singleton: true, strictVersion: true, requiredVersion: 'auto', includeSecondaries: false, build: 'package' },
    // '@angular/platform-browser': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
    // '@angular/platform-browser-dynamic': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
    '@angular/router': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
    // '@angular/forms': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
    '@jsverse/transloco': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
    '@angular/service-worker': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
    '@angular/common/locales/de': { packageInfo: { entryPoint: '@angular/common/locales/de', esm: true, build: 'package' } },
    '@angular/common/locales/en': { packageInfo: { entryPoint: '@angular/common/locales/en', esm: true, build: 'package' } },
    '@angular/common/locales/fr': { packageInfo: { entryPoint: '@angular/common/locales/fr', esm: true, build: 'package' } },
    '@angular/common/locales/ar': { packageInfo: { entryPoint: '@angular/common/locales/ar', esm: true, build: 'package' } },
    '@angular/common/locales/id': { packageInfo: { entryPoint: '@angular/common/locales/id', esm: true, build: 'package' } },
    '@angular/common/locales/zh': { packageInfo: { entryPoint: '@angular/common/locales/zh', esm: true, build: 'package' } },
    '@angular/common/locales/zh-Hans': { packageInfo: { entryPoint: '@angular/common/locales/zh-Hans', esm: true, build: 'package' } },
    '@angular/common/locales/zh-Hant': { packageInfo: { entryPoint: '@angular/common/locales/zh-Hant', esm: true, build: 'package' } },
    '@angular/common/locales/ja': { packageInfo: { entryPoint: '@angular/common/locales/ja', esm: true, build: 'package' } },
    '@angular/common/locales/ms': { packageInfo: { entryPoint: '@angular/common/locales/ms', esm: true, build: 'package' } },
  }),
},

now AFAIK, with the ignoreUnusedDeps feature you don't need to manually define all the locales. I am not 100% sure but have a look if this fixes it:

shared: {
  ...share({
    // test minimal share
    '@angular/core': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package', chunks: true, includeSecondaries: {keepAll: true}},
    '@angular/common': { singleton: true, strictVersion: true, requiredVersion: 'auto',build: 'package', chunks: true, includeSecondaries: {resolveGlob: true}},

    '@angular/common/http': { singleton: true, strictVersion: true, requiredVersion: 'auto', includeSecondaries: false, build: 'package' },
    // '@angular/platform-browser': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
    // '@angular/platform-browser-dynamic': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
    '@angular/router': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
    // '@angular/forms': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
    '@jsverse/transloco': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' },
    '@angular/service-worker': { singleton: true, strictVersion: true, requiredVersion: 'auto', build: 'package' }
  })
},

The reason I suggested build: 'package' is because, by default ESbuild will bundle all externals in 1 single bundle step with every defined external as "entryPoint". That's cool but can create a lot of chunk files since everything is all connected.
You can fix this by marking some big packages as build: 'package', which could create a compacter bundle of that package/external. Even more compact if you disable chunks for that "package" since it is now an isolated bundle. The trade-off is that when you disable chunks, that every entrypoint (for @angular/core the entrypoints are all 'import paths' like @angular/core/rxjs-interop and @angular/core/xyz) will contain all the imports of that bundle so it might grow a bit in size. It might outweight your chunking issue though.

Finally, if you're using the new orchestrator, there is a new feature that is pretty cool. it's called "denseChunking" and it will group all chunk imports per external (you can see the output in your remoteEntry.json), this way you can see where most chunks come from.

Enough to think about. Feel free to share your findings and let me know if it helps!

[ladler1]

Thank you very much for your detailed answer this helps a lot. Interestingly after applying all your suggestions my observation is that with the new version the number of chunks increased. Before 63 chunk-* after 87 chunk-*. But interestingly the problem is solved by using the new versions:
The chunks are not in the pending state for a longer time and the rebuild is fast.

[Aukevanoost]

Oh great! You can (with denseChunking enabled) always check where most chunks come from. Feel free to play around with the settings to see what works best for you.