The "No entry point found for the devextreme library" warning causes errors when loading the remote

[Tom]

Hello,

I'm posting this message on behalf of the DevExtreme UI kit support team.

I'm trying to check the devextreme and devextreme-angular packages are compatible with the native-federation plugin.

Currently I ran into the issues described in my test repository:

module-federation-with-devextreme

You'll find readme.md that describes the steps I did and actual\expected results.

Reposted instructions

To Reproduce the issue

Steps

1 Run npm install to install all dependecies
2a. Run npm run start:all to check the shell application:

• Open http://localhost:4200
• Switch to the MFE2 item
  2b. Run ng serve mfe2
  Open http://localhost:4202/

Actual Results:

The build process shows the following warnings:

[1] INFO Building federation artefacts
[1] WARN No entry point found for devextreme
[1] WARN If you don't need this package, skip it in your federation.config.js or consider moving it into depDependencies in your package.json
[1] WARN No meta data found for shared lib devextreme

The browser throws the following errors:

app.routes.ts:4 Error: Unable to resolve specifier 'devextreme-angular/ui/accordion' 
_angular_core-17_3_1-dev.js:3806 ERROR Error: Unable to resolve specifier 'devextreme/core/dom_adapter' 

Additional information:

I see that the ESBuild takes all possible modules from devextreme-angular and devextreme even if they were not imported.
E.g., the browser page shows the error related the devextreme-angulr/ui/accordion module while I didn't explicitly export it

I also had to skip the devextreme-angular/server module in federation.config.js because it contains incompatible the stream package although an application doesn't use SSR.

skip: [
    'devextreme-angular/server',

Otherwise, you'll run into issue described at #523

At the first glance it looks like our packages either don't have the required format or we need some additional settings to make them work with your plugin.

Could you please consult me to understand if we need either some minor changes in federation.config.js config or major re-work in our packages formats to make devextreme work in an Angular application built with Native Module Federation?

[Manfred Steyer]

Thanks for pointing this out. We had indeed some troubles with the package format used here. I think, its more the underlying traditional code that is wrapped by Angular-specific libs. I'm going to look into this in more detail next week when I'm back in the office again.

[Irakli Gvatua]

Hi, is there any news to solve this problem?

[MarioGit1]

Hi, we are currently using module federation, DevExtreme, and Angular 16 in a project, and this combination runs smoothly. Now, we are planning to update to Angular 17 and utilize their new build pipeline. We have switched to native federation, and everything works fine without sharing the DevExtreme modules. However, when we attempt to share the modules, we encounter the same issue described by @artem-kurchenko. Have there been any updates or news regarding this issue?

[Manfred Steyer]

Hi @artem-kurchenko,

Thanks for your patience. I've been at several conferences in the previous weeks.

The reason for this is that the packages devextreme, devextreme-angular, etc. don't describe their entry points.

Please have a look at the exports field at [1] and [2].

I think generating this meta data would be in general a good idea, because it's now defined by node and by the Angular Package Format.

The package.json files in @angular/core, @angular/common, @angular/material, etc. can be used as a template.

[1] https://nodejs.org/api/packages.html#package-entry-points
[2] https://angular.io/guide/angular-package-format#exports

[MarioGit1]

Thank you, Manfred, for checking. I had suspected something like that, so now it's DevExpress's turn. For us, this means we have to resort to WebPack. It's disappointing; Native Federation and esbuild looks promising and felt good to use, but unfortunately, we can't use it under these circumstances.