It would be helpful if anyone with slow rebuilds could set METEOR_PROFILE=20 or use qualia:profile and send me the profile for a rebuild.
2 Likes
Will checkout qualia:profile, I’ve never seen before. Here is a profile from after moving back to imports.
Edit: moved profile to dm for thread readability. Basically babel is taking a long time. 70% of the build time was 4.5s on babel compile.
1 Like
I’m also still using /imports - I was going to get rid of it at one point, but the truth is, I kind of like it. It’s where all the source goes that can be used anywhere. For stuff that’s going to be either on the server or client only, I put those in the client and server folders. I do use mainModule configuration with this set up. Maybe that’s why it’s pretty fast for me.
This is how I have all my projects set up as well.
Very useful sources! Thank you for sharing
1 Like
I’ve built a very basic, mostly working implementation of HMR. At this point it is only able to reload files that use module.exports and require, has many situations where it doesn’t work properly, and doesn’t have a client api so it reloads any file that has changed along with the files that imported it.
I created a video showing HMR with the app created by meteor create --react.
10 Likes
Oh wooow @zodern that’s just awesome!! beautiful to watch, truly impressive, exciting and meteory 
Is it using react fast refresh?
Edit: I guess the HMR API would be the same, but I’m referring to the demo you shared specifically.
1 Like
Right now there is nothing specific to react in the HMR implementation. I am focusing on the basic aspects that would be required to implement HMR for any view layer.
In the app used in the video it unmounts the previous root component every time. Component state would be lost between reloads, but react boilerplate and many apps do it this way since it is simple and works more reliably than the solutions that existed before react fast refresh.
4 Likes
Got it, it make sense to have a general HMR approach/API for all view layers.
So I guess React Fast Refresh and alike are just needed to maintain the state of the component when a module is hot replaced.
That’s amazing! You are a wizard. I need to learn more about the ins and outs of the build process.
Will this be cross UI layer? (Vue, React, etc)?
Yes, I think it is, this is becoming standard HMR API for the build system and zodern alluded to that here, basically, the build system tells the client which files changed and push the changed modules to the system and the view system refresh the client while maintaining the state. React Fast Refresh is the new generate of React hot reload, they’ve used internal APIs to make it more robust, the previous one had many flaws and gotchas.
But I think there is another approach to get fast refresh working by using the dev server bundlers (such as Snowpack or Vite during dev, this approach also works across all the view and I think faster than HMR, since it skips the transpilation process completely and uses the new browser imports to ship only the changed module ES module, however there is limitation with SSR and we’ve to stub meteor imports, I’ve made a case for this approach here…
Note that pub/sub, methods doesn’t work here, this is purely front-end with stubs for the backend calls, so the flow here is to create the front-end. However, there might be a way to get the basic stubs to actually work using library like SimpleDDP or injecting Meteor script to the public html.
4 Likes
The standard for ESM-HM is being defined here
I really think is a great opportunity for Meteor to implemented it during development. When local file is changed, as long as it is added to the depedancy graph within this library, the library will doctorate the module with some methods (apply etc), and ship to the client via websockets, then the client side of the library will handle the refresh. @zodern I really encourage you to take a look at this approach, since you showed interested in HMR, I think it is the most sensible way to get HMR is Meteor and it’ll be update to with snowpack and rest of the ESM bundlers. Basically those libraries are piggybacking on the ES modules import implementation by the browser to get HMR working.
4 Likes
I opened a PR to add HMR and React Fast Refresh to Meteor: https://github.com/meteor/meteor/pull/11117
It is far from ready to be merged, but it should be usable for most apps.
9 Likes
Wowow this stuff should also end up in the guide. Really awesome stuff!
@zodern if a react file is changed within a Meteor package, would it still trigger a fast refresh?
Some of us have package based architectures and some views are within Meteor packages.
This PR only implements it for app code. There are additional challenges with HMR for packages, so I plan to implement it afterwards to reduce the scope of the PR. Thanks for asking about it because I was wondering how useful it would be.
3 Likes