Add the ability to not regenerate types during hmr

[leanllg]

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

• Read the Contributing Guidelines.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[jbroma]

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?

[zmzlois]

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]

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

[ScriptedAlchemy]

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?

[jbroma]

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]

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

[ScriptedAlchemy]

@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

[steven-pribilinskiy]

You can give a shot to the webpack-module-federation-types-plugin, though it was not tested with v2-enhanced.

That package recently got an update to compile types in a worker, this way type generation is completely decoupled from compilation. Results can be seen on screenshots in the PR.

[ScriptedAlchemy]

There's a PR open already. We also use worker. That's not the issue; the issue is we use process assets. So the pipeline blocks the seal phase, which bottlenecks. In the future, we will use outputFileSystem directly, which will allow full non-blocking HMR.

[ScriptedAlchemy]

Need @jbroma to validate then ill merge

[steven-pribilinskiy]

Thx for the heads up Zack! I hope we can deprecate webpack-module-federation-types-plugin in favor of native solution.

[ScriptedAlchemy]

Thx for the heads up Zack! I hope we can deprecate webpack-module-federation-types-plugin in favor of native solution.

Hey! Feel free to contribute your ideas to our repo if you have some. 🥰 The TS plugin is a monster. It does runtime browser type discovery as well, so dynamic remotes that can't be statically analyzed are posted from the browser back to the DTS engine. I don't work with TS in general, so I'm not much use on this feature set beyond plugin APIs. So if you ever want to contribute, we would love it.

One aspect you might be interested in is that currently our DTS manager does not extract third-party package types. For example, if you have an exposed module or shared module and they have a nested package like Redux, the typing for the underlying Redux API isn't created.
There are a few GitHub issues about it. We would love some help there if you're up for it. 😅

[jbroma]

Need @jbroma to validate then ill merge

Hey, sorry for the late reply, I can confirm the canary fixes the issue 👍

[ScriptedAlchemy]

Merged