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

[artem-kurchenko]

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. ```js 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?

[manfredsteyer]

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?

[manfredsteyer]

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.

[manfredsteyer]

This might be correct for the time being. I hope that DevExtreme will get this metadata, as it correlates with the npm standard and the Angular Package Format.

Just one idea: Perhaps writing a little generator that augments the meta data can help in the meantime.

[zmpo]

Hi , @artem-kurchenko Is your team currently in research? Or is it that the team is not convenient to make changes or facing difficulties?

[artem-kurchenko]

Thank you for taking a look into this issue, @manfredsteyer.

We'll look into these propose and reopen this issue if further clarifications are needed. I'm closing this thread for now.

@zmpo we didn't start any research as the team is focused in 24.1 beta and release. If we decide to work on this issue we'll publish updates in our Angular Roadmap

In the meantime, it's better to keep all packages that contain "devexpress" and "devextreme" outside the "shared" section (add them to the "skip" section)