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
{{ message }}
Repository navigation
[Meta] Releasing this Plugin as "Fast Refresh" capable #1
This issues tracks what is missing before this plugin attains "feature-parity" with the RN implementation and is representative of the "fast-refresh" branding.
Tasks
Error Recovery
Module Import Errors
Static Imports
Dynamic Imports (Lazy)
Add/Remove Imports
Concurrent Mode
Syntax Errors
File Level
Component Level
Life-cycle Method Level
Function Return Level
Runtime Errors
Rendering Errors
React-related Errors
Root Mounting Errors (Full Refresh)
Error on Initial Mount
Accidental Root Unmount
Component Auto-Registration
Function Components (via Babel plugin)
Loader would also pickup false-negatives from the plugin
@pmmmwh What needs to happen in order to get this working with webpack 5? I haven't spent much time looking into the changelog there.
@maisano
It has nothing to do with the flow/logic, it is mostly related to hook signatures changing:
The afterResolve now returns resolvedData with a field createData - which is the equivalent of webpack 4 resolveData. The hook is also switched to a series bail hook so we can't return the modified data.
The require hook in mainTemplate now switched to return chunk context instead of the actual chunk. To effectively detect entry modules, we now have to get iterable entry modules from the chunkGraph then loop them through.
Direct references to the normal module loader (which I used to detect hot context here) is completely removed and we now have to get it via webpack.NormalModule.getCompilationHooks(compilation).loader.
In fact - I have already implemented these changes, locally. But because webpack 5 is still in alpha, I am not sure if releasing them at this stage is a good move.
Speaking of versions, I am still debating on the proper range of webpack versions to support. It would be easiest to only support webpack 4+, but I do understand that webpack 3 is still being used by a lot of people.
@gaearon
I have been working on the error box integration for a few days now - and have got to a point where I would like your input on a few things:
I was trying to integrate with react-error-overlay, like how react-dev-utils did for CRA. However, I read from here that the overlay is going to get a rewrite soon - mind tell me a little bit more about that?
(edited to better phrase the question) I have made recovery from runtime errors and build-time errors both working, utilizing the exact same approach from react-dev-utils and webpack-dev-server's overlays.
For build errors, I haven't found an alternative to having a socket server in-place, whether it is from webpack or it is built into the plugin. Initially, I achieved this by building a socket server into the plugin because I didn't want to rely on WDS - but thinking about it more, I probably was wrong, and that would probably make things more complicated than what it should be. Not to mention that addressing the needs of every webpack + React user is probably unrealistic. My new proposal to make this work:
Baseline - allow zero-configuration experience with WDS
For advanced users, provide an express style middleware that will work with webpack-dev-middleware which creates an endpoint that does the same thing as WDS's stats emitter.
For runtime errors, if we go for a similar experience that react-error-overlay provides, a sourcemap (cheap-module-source-map in particular) have to be generated. I am not sure if enforcing this is a good idea, especially when this have implications in using browser debuggers. I can still provide insights on what the error is about and the stack, just not as elegant as having the source visible for debugging.
If I was looking to lend a hand here, what would be the most impactful thing to look into?
Maybe it would be helpful for two or three of us to chat? (Assuming you'd like a hand.)
Nope - we haven't talked yet. I definitely would like a hand 😃 . It would be great if you can provide more context on the error-box experience @bvaughn .
👋 @bvaughn – we haven't met yet–I have some time this week if we want to try. Are you on PST?
@pmmmwh – assuming this is you, can you open your DMs? It'd be easier to coordinate there.
@maisano Yep that's my long abandoned Twitter account - I have opened my DMs.
Seems to be working better than react-hot-loader ever did. Mainly because we mount a few different page (many of which are named export making manually wrapping them in hot() particularly tedious and ugly). Auto-registration is awesome!
Has there been any further discussion about implementing the error overlay? The discussion kind of trailed off. I'm available to help with that if you want assistance.
In Metro, this is handled by re-evaluating the parent when this happens, but I am not sure if this can be done in Webpack.
I think we should just force a full page reload for now. It would indeed be nice if webpack provided a way to do this but I don't think it's currently possible. We can definitely detect it, see the "is boundary invalidated" code in Metro.
I did reference that, and have already implemented the check/bail out for full refresh 😺 .
Another case you'll notice affected by this is changing component from exporting a class to a function.
Yes, basically any combinations of prev/next with a function would hit that.
Regarding react-error-overlay. Are there any concerns about it relying too much on CRA assumptions? Like I'm not sure how stack symbolication works but does it load the correct .map file when there's multiple entry points etc?
I think it works with multiple entry points. The main assumptions to me that would fail in any projects not from CRA would be the custom dev server middlewares and cheap-module-source-map (devtool). It also won't work with resource queries, custom socket implementations nor webpack under proxy servers, but I would consider them as advanced use cases anyhow, and thus will definitely need custom work.
I think it works with multiple entry points. The main assumptions to me that would fail in any projects not from CRA would be the custom dev server middlewares and cheap-module-source-map (devtool).
I'll give the branch another test tomorrow now that it's updated. I'm using it multi-compiler setup w/ multiple entrypoints per compiler.
I did reference that, and have already implemented the check/bail out for full refresh 😺 .
I'll double check again as well, but that seemed to be working form my testing as well, and was respecting the hotOnly flag from the webpack dev middleware.
Hey all - Thanks for participating in the conversation 😺!
I am happy to announce v0.1.0 is out now 🎉
Reacted by Hamza Mihai Daniel, Constantine Antonakos, Bjarki Hall, 迈宇, Rowan Savage, Swashata Ghosh, Hadeeb Farhan and cbdeveloper
Reacted by Hamza Mihai Daniel and cbdeveloper
Reacted by Fredrik Höglund, Constantine Antonakos, thermarthae, Emrah Bilbay, Sibelius Seraphini, Hamza Mihai Daniel, Kaman L, Kyle Holzinger, Rudolfs Pukitis and nilscox
Reacted by Fredrik Höglund, Constantine Antonakos, thermarthae and Hamza Mihai Daniel
Reacted by Hamza Mihai Daniel, Constantine Antonakos, Tim Ellenberger, Ryan Stelly and Martynas Kadiša
Hi @pmmmwh, Thank you for your awesome work here. I would like to integrate this with https://wpack.io (https://github.com/swashata/wp-webpack-script) (A CRA like tooling for WordPress) and there I am proxying WordPress site through browser-sync with Webpack Dev Middleware and Webpack hot middleware.
I see in your todo list that we need to have express like middleware to cater advance WDM users. Since I am one of those users, I would like help in anyway I can to make this possible. Any tips on where to get started?
Hi @pmmmwh, Thank you for your awesome work here. I would like to integrate this with https://wpack.io (https://github.com/swashata/wp-webpack-script) (A CRA like tooling for WordPress) and there I am proxying WordPress site through browser-sync with Webpack Dev Middleware and Webpack hot middleware.
I see in your todo list that we need to have express like middleware to cater advance WDM users. Since I am one of those users, I would like help in anyway I can to make this possible. Any tips on where to get started?
You can checkout #23 - the solution shown there is not perfect (because of entrypoint ordering issues). I was thinking to draft an API to allow custom entry ordering, but afaik WHM seems to be the only know hot client using window to inject, so another way to prevent complicating things is to custom handle detection of that entry in the plugin. To do that you can see the section commented as inject entrypoints in the index.
Really appreciate the work you're doing here and looking forward to using this.
I was looking at #36 and was also wondering if things like server-side rendering support will be included in this becoming officially "fast refresh" capable?
I'd be happy to help with this, so far I've been trying to use this with Next.js but after trying to configure it for a few hours I can't get state in hooks to persist between renders, even though it's using webpack and HMR on the client side.
I do have it ignoring webpack compiles on the server side, since otherwise it tries to access window
I was looking at #36 and was also wondering if things like server-side rendering support will be included in this becoming officially "fast refresh" capable?
SSR support will probably be something that have to be case by case unfortunately. I don't have a lot of knowledge on specifically how SSRed components are being hydrated, so any insights will help.
I'd be happy to help with this, so far I've been trying to use this with Next.js but after trying to configure it for a few hours I can't get state in hooks to persist between renders, even though it's using webpack and HMR on the client side.
For Next.js it's difficult because their Webpack setup is indeed very complicated. Next's maintainers have shown interest in adding this, so hopefully after we tackle all the prerequisites it can be available to everyone in that ecosystem.
SSR support will probably be something that have to be case by case unfortunately. I don't have a lot of knowledge on specifically how SSRed components are being hydrated, so any insights will help.
Initially I was expecting some difference because I wasn't sure how SSR build setups work, and the implementation here was quite rough too.
With the latest iteration I think there shouldn't be any difference in Fast Refresh compatibility, but there might still be some difference in the experience due to the libraries are being used (e.g. React.lazy v.s. loadable-components) and how builds are being set up (custom SSR setups will require more config).
Activity
maisano commentedon Sep 19, 2019
@pmmmwh What needs to happen in order to get this working with webpack 5? I haven't spent much time looking into the changelog there.
pmmmwh commentedon Sep 20, 2019
@maisano
It has nothing to do with the flow/logic, it is mostly related to hook signatures changing:
afterResolvenow returnsresolvedDatawith a fieldcreateData- which is the equivalent of webpack 4resolveData. The hook is also switched to a series bail hook so we can't return the modified data.requirehook inmainTemplatenow switched to return chunk context instead of the actual chunk. To effectively detect entry modules, we now have to get iterable entry modules from thechunkGraphthen loop them through.webpack.NormalModule.getCompilationHooks(compilation).loader.In fact - I have already implemented these changes, locally. But because webpack 5 is still in alpha, I am not sure if releasing them at this stage is a good move.
Speaking of versions, I am still debating on the proper range of webpack versions to support. It would be easiest to only support webpack 4+, but I do understand that webpack 3 is still being used by a lot of people.
pmmmwh commentedon Sep 20, 2019
@gaearon
I have been working on the error box integration for a few days now - and have got to a point where I would like your input on a few things:
react-error-overlay, like howreact-dev-utilsdid for CRA. However, I read from here that the overlay is going to get a rewrite soon - mind tell me a little bit more about that?react-dev-utilsandwebpack-dev-server's overlays.expressstyle middleware that will work withwebpack-dev-middlewarewhich creates an endpoint that does the same thing as WDS's stats emitter.react-error-overlayprovides, a sourcemap (cheap-module-source-mapin particular) have to be generated. I am not sure if enforcing this is a good idea, especially when this have implications in using browser debuggers. I can still provide insights on what the error is about and the stack, just not as elegant as having the source visible for debugging.gaearon commentedon Sep 21, 2019
Do you two wanna do a video call next week with me? Might be easier to talk through all issues.
maisano commentedon Sep 22, 2019
Sounds good. I'm on EST (GMT-4) and generally pretty flexible, so let me know what works for you all.
pmmmwh commentedon Sep 22, 2019
Sounds good to me too. I am on GMT+8 and also pretty flexible. What time will work for you Dan?
pmmmwh commentedon Sep 23, 2019
My progress is tracked on this branch. It is pretty rough though.
bvaughn commentedon Sep 30, 2019
Did the three of you ever end up talking?
If I was looking to lend a hand here, what would be the most impactful thing to look into?
Maybe it would be helpful for two or three of us to chat? (Assuming you'd like a hand.)
maisano commentedon Sep 30, 2019
👋 @bvaughn – we haven't met yet–I have some time this week if we want to try. Are you on PST?
@pmmmwh – assuming this is you, can you open your DMs? It'd be easier to coordinate there.
bvaughn commentedon Sep 30, 2019
Hi 👋 I am located in California, so yeah PST. Happy to chat for a bit to ramp up context if that would be helpful.
pmmmwh commentedon Oct 1, 2019
Nope - we haven't talked yet. I definitely would like a hand 😃 . It would be great if you can provide more context on the error-box experience @bvaughn .
@maisano Yep that's my long abandoned Twitter account - I have opened my DMs.
bvaughn commentedon Oct 1, 2019
@maisano Want to start a thread between the three of us on Twitter?
charrondev commentedon Oct 31, 2019
Just wanted to say that I started testing it our setup here:
https://github.com/vanilla/vanilla/pull/9509
Seems to be working better than react-hot-loader ever did. Mainly because we mount a few different page (many of which are named export making manually wrapping them in
hot()particularly tedious and ugly). Auto-registration is awesome!Has there been any further discussion about implementing the error overlay? The discussion kind of trailed off. I'm available to help with that if you want assistance.
14 remaining items
pmmmwh commentedon Nov 4, 2019
I did reference that, and have already implemented the check/bail out for full refresh 😺 .
Yes, basically any combinations of prev/next with a function would hit that.
I think it works with multiple entry points. The main assumptions to me that would fail in any projects not from CRA would be the custom dev server middlewares and
cheap-module-source-map(devtool). It also won't work with resource queries, custom socket implementations nor webpack under proxy servers, but I would consider them as advanced use cases anyhow, and thus will definitely need custom work.charrondev commentedon Nov 5, 2019
I'll give the branch another test tomorrow now that it's updated. I'm using it multi-compiler setup w/ multiple entrypoints per compiler.
I'll double check again as well, but that seemed to be working form my testing as well, and was respecting the
hotOnlyflag from the webpack dev middleware.pmmmwh commentedon Dec 6, 2019
Hey all - Thanks for participating in the conversation 😺!
I am happy to announce
v0.1.0is out now 🎉swashata commentedon Dec 27, 2019
Hi @pmmmwh, Thank you for your awesome work here. I would like to integrate this with https://wpack.io (https://github.com/swashata/wp-webpack-script) (A CRA like tooling for WordPress) and there I am proxying WordPress site through browser-sync with Webpack Dev Middleware and Webpack hot middleware.
I see in your todo list that we need to have express like middleware to cater advance WDM users. Since I am one of those users, I would like help in anyway I can to make this possible. Any tips on where to get started?
pmmmwh commentedon Dec 28, 2019
You can checkout #23 - the solution shown there is not perfect (because of entrypoint ordering issues). I was thinking to draft an API to allow custom entry ordering, but afaik WHM seems to be the only know hot client using
windowto inject, so another way to prevent complicating things is to custom handle detection of that entry in the plugin. To do that you can see the section commented as inject entrypoints in the index.phaistonian commentedon Jan 2, 2020
@pmmmwh So, a solution for this, i.e support for hot middleware, is or will on its way?
ps: Happy 2k20!
mattfwood commentedon Jan 29, 2020
Really appreciate the work you're doing here and looking forward to using this.
I was looking at #36 and was also wondering if things like server-side rendering support will be included in this becoming officially "fast refresh" capable?
I'd be happy to help with this, so far I've been trying to use this with Next.js but after trying to configure it for a few hours I can't get state in hooks to persist between renders, even though it's using webpack and HMR on the client side.
I do have it ignoring webpack compiles on the server side, since otherwise it tries to access
windowpmmmwh commentedon Feb 21, 2020
SSR support will probably be something that have to be case by case unfortunately. I don't have a lot of knowledge on specifically how SSRed components are being hydrated, so any insights will help.
For Next.js it's difficult because their Webpack setup is indeed very complicated. Next's maintainers have shown interest in adding this, so hopefully after we tackle all the prerequisites it can be available to everyone in that ecosystem.
pmmmwh commentedon Jul 8, 2020
Roadmap to v1 Stable
Core
Testing
Bundling
Overlay
Ecosystem
Release
gaearon commentedon Jul 8, 2020
I wouldn't expect any differences when SSR is on.
pmmmwh commentedon Jul 8, 2020
Initially I was expecting some difference because I wasn't sure how SSR build setups work, and the implementation here was quite rough too.
With the latest iteration I think there shouldn't be any difference in Fast Refresh compatibility, but there might still be some difference in the experience due to the libraries are being used (e.g. React.lazy v.s. loadable-components) and how builds are being set up (custom SSR setups will require more config).
[-]Releasing this Plugin as "Fast Refresh" capable[/-][+][Meta] Releasing this Plugin as "Fast Refresh" capable[/+]bdanzer commentedon Jan 1, 2021
pmmmwh commentedon Jan 2, 2021
@bdanzer Please see #226 (comment)
nyngwang commentedon Feb 25, 2024
Post here for attention: I believe error recovery is now completely broken with
webpack-dev-server@5, see #806 for reference.