Some package.json configurations from 3rd party libs lead to bundling differences between angular and native federation

[JanWahl]

Hello, I used jspdf-autotable and it seems that with their package.json configuration the @angular-architects/native-federation:build executor bundles the commonjs variant instead of the esm one.

The angular builder uses the esm. This came to my attention because the default export worked differently for a "pure" angular app and a nf-microfrontend In the microfrontend i had to use

import autoTable from 'jspdf-autotable'; autoTable.default(...)

for the microfrontend instead of just

import autoTable from 'jspdf-autotable';

autoTable(...)

to access the default import.

This is not a huge issue for me, just adding the package to the skip-array of the federation.config.ts circumvented the problem for me since I don't need to share the package between the microfrontends.

[mouadennaciri]

I have the same case with other packages.

[manfredsteyer]

Thanks for pointing this out. Yes, this is indeed different. The reason is that with Native Federation such entry points end up in ESM bundles of their own and not everything can be converted from commonjs to ESM.

I've seen, this package also has en ESM entrypoint. It seems to be jspdf-autotable/es instead of jspdf-autotable. Does it work as expected when you import from this one?

[JanWahl]

There might be a problem with the jspdf-autotable package itself. For some reason the compiler can't find the other entry point, even though it is listed in the package.json and the file it is pointing to exists. This is the only package i had this problem with so far.

[manfredsteyer]

I see.

We are really in a fortunate position in the Angular community, as the Angular Package Format most libs follow, give us proper ESM bundles.

Best wishes, Manfred