You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When rsdoctor analyzed a certain business MF project, the build analysis was very slow. It was found that the stats.json containing chunks and modules was nearly 4G, and that each module's issuer path contained the container entry module, and the identifier of the container entry module was 22KB, that string contains 100+ arrays and there were a total of 13,000 modules, resulting in a very large stats.json, which caused rsdoctor to analyze very slowly using stats.json.
What problem does this feature solve?
When rsdoctor analyzed a certain business MF project, the build analysis was very slow. It was found that the stats.json containing chunks and modules was nearly 4G, and that each module's issuer path contained the container entry module, and the identifier of the container entry module was 22KB, that string contains 100+ arrays and there were a total of 13,000 modules, resulting in a very large stats.json, which caused rsdoctor to analyze very slowly using stats.json.
rspack mf logic on generating the identifier of the container entry module..
We are looking forward to optimizing the issue of overly long identifiers of the container entry module of the issuerPath in the stats.json file.
MF core same issue: module-federation/core#2598
What does the proposed API of configuration look like?
It is hoped that the identifier of the container module in the issuerpath can be optimized by hash or other volume reduction.
The text was updated successfully, but these errors were encountered: