Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Optimizing the problem of overly long identifiers of the container entry module of the issuerPath in the stats.json file #6776

Open
easy1090 opened this issue Jun 12, 2024 · 0 comments
Assignees
Labels
feat New feature or request

Comments

@easy1090
Copy link
Collaborator

easy1090 commented Jun 12, 2024

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.

@easy1090 easy1090 added feat New feature or request pending triage The issue/PR is currently untouched. labels Jun 12, 2024
@LingyuCoder LingyuCoder removed the pending triage The issue/PR is currently untouched. label Jun 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants