module-federation / core

Module Federation is a concept that allows developers to share code and resources across multiple JavaScript applications
https://module-federation.io/
MIT License
1.54k stars 237 forks source link

Add the ability to not regenerate types during hmr #3110

Open leanllg opened 3 weeks ago

leanllg commented 3 weeks ago

Clear and concise description of the problem

Generate module federation types makes rsbuild hmr slow(from 0.4s to 4s). When I set disableHotTypesReload to true, it still regenerate types. And I find disableHotTypesReload option can't control this behavior. So it would be better to have an option to not generate types during hmr to improve hmr speed.

Suggested solution

Maybe stop regenerate types when provider set disableHotTypesReload to true or just add a new opition.

Alternative

No response

Additional context

No response

Validations

jbroma commented 2 days ago

This is still a valid issue,

Currently, the options in dev configuration don't seem to work as expected.

Correct me if I'm wrong, but I would expect that setting dev to false would ultimately turn off any sort of build performance impact after the initial build? Currently, with DTS enabled we're seeing slow downs of like 4x - 5x in HMR time.

Are there any plans to make DTS faster with things like https://github.com/web-infra-dev/rspack/pull/8097 on the horizon?

zmzlois commented 2 days ago

This is still a valid issue,

Currently, the options in dev configuration don't seem to work as expected.

Correct me if I'm wrong, but I would expect that setting dev to false would ultimately turn off any sort of build performance impact after the initial build? Currently, with DTS enabled we're seeing slow downs of like 4x - 5x in HMR time.

Are there any plans to make DTS faster with things like web-infra-dev/rspack#8097 on the horizon?

have you tried this? https://www.typescriptlang.org/tsconfig/#isolatedDeclarations

jbroma commented 2 days ago

@zmzlois haven't tried isolatedDeclarations on their own but now that I think of it it might still give us a significant improvement 🤔

ScriptedAlchemy commented 2 days ago

This is still a valid issue,

Currently, the options in dev configuration don't seem to work as expected.

Correct me if I'm wrong, but I would expect that setting dev to false would ultimately turn off any sort of build performance impact after the initial build? Currently, with DTS enabled we're seeing slow downs of like 4x - 5x in HMR time.

Are there any plans to make DTS faster with things like https://github.com/web-infra-dev/rspack/pull/8097 on the horizon?

What if you set dts: false?

jbroma commented 2 days ago

This is still a valid issue, Currently, the options in dev configuration don't seem to work as expected. Correct me if I'm wrong, but I would expect that setting dev to false would ultimately turn off any sort of build performance impact after the initial build? Currently, with DTS enabled we're seeing slow downs of like 4x - 5x in HMR time. Are there any plans to make DTS faster with things like web-infra-dev/rspack#8097 on the horizon?

What if you set dts: false?

dts: false works but disables types completely (as expected)

ScriptedAlchemy commented 2 days ago

Ahh you just want initial type gen. Then it to stop watching subsequent updates?

ScriptedAlchemy commented 2 days ago

@jbroma try this: 0.0.0-next-20241114065146

Im wondering if i can change the plugin so that initial build uses compilation.emitAsset and HMR update builds just use fs.writeFileSync, so that the hook does not await type generation and just lazily writes the updated file back to disk whenever it completes. Thoughts?
This way it would always remain updated, but would be delayed in synchronizing with the others - in order to not block the bundler workflow. Only the initial compile would be blocking in order to ensure that type generation happens