-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
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
fix: fast refresh stops on needed bail outs #11105
Conversation
Fast Refresh requires the HMR runtime to support bail out behaviour (we do not do so within the core runtime as it has to be platform agnostic) - and currently webpackHotDevClient does not do so properly as it circumvents the logic for forced reloads completely when using Fast Refresh. The changes done here ensures that: - If Fast Refresh is not enabled, we would always bail out to a forced reload; - If Fast Refresh is enabled and there are updated modules, it indicates the update has at least partially executed, and we can rely on Fast Refresh being resilient to errors and skip the forced reload; - If Fast Refresh is enabled and there are none updated modules, it indicates the update cannot be executed without being inconsistent (i.e. Fast Refresh bailed out), we would bail out to a forced reload.
Updated heuristic to cover more cases (to be on the safe side) where we would force a reload, especially when Webpack signifies that the HMR update is aborted or failed completely (indicating applying the update would yield inconsistency). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't tested yet, but this sounds great. We'll try to get this into the next release - thanks @pmmmwh!
Thanks! Looking forward to getting these enhancements out in v5! |
Fast Refresh requires the HMR runtime to support bail out behaviour (we do not do so within the core runtime as it has to be platform agnostic) - and currently webpackHotDevClient does not do so properly as it circumvents the logic for forced reloads completely when using Fast Refresh.
The changes done here ensures that:
abort
orfailed
, it indicates the update cannot be executed without being inconsistent (i.e. Fast Refresh bailed out), we would bail out to a forced reload.To verify the impact of this change:
App.js
with multiple exports (e.g. [BUG]: Silently fails with multiple exports pmmmwh/react-refresh-webpack-plugin#426)App.js
with anything. Without this PR changes would not propagate on screen.To verify addendum to this change (error recovery):
App.js
throw new Error('no')
within theApp
component, compilation should show the error overlayApp
should HMR properly without forced refreshApp
should HMR properly without forced refreshThis should:
Fixes #9904
Fixes #9913
Fixes #9984
Fixes Partially #10078
Fixes #10287
Fixes #10539
Fixes #10606
Fixes #11087