React Hotloading in native Meteor is ready (i.e. no webpack)


Using gadicc:ecmascript-hot@0.0.9-rc.2 I’m getting the error:

Unknown plugin "react-transform" specified in "/Users/clayne/workspace/r3ntr_meteor/.babelrc.env.development" at 0, attempted to resolve relative to "/Users/clayne/workspace/r3ntr_meteor"


Yes sorry it was an error in the README but @xcv58 fixed it. Happy you found it though in the meantime!

Did you npm install --save babel-plugin-react-transform and does `"/Users/clayne/workspace/r3ntr_meteor/node_mpdules/babel-plugin-react-transform’ exist? If it does then I guess this doesn’t work on MacOS and I’ll look into it when I’m home. Let me know.


Your biggest fanboi checking in :smile: to say I’m still using this and was thinking about this package when rc2 was released.

Admittedly, I haven’t been as active in bug reports. Have been evaluating TDD and testing frameworks. It’s been a big time investment and hopefully it will pay off soon.

It has to be said that I am interested by the release of another certain package in this area (webpack:webpack), having tried that in its earlier incarnation, it was a bit unstable, required too much time to configure and also had issues of not being able to hot reload in many cases like your package.

However, I have glimpsed workflow Nirvana working with your package (as can be observed by my previous over enthusiastic posts) and that’s why I’m still here.

I’m convinced if people give this a go, they would see the time benefits and the fact it keeps the same app state alot of the time drastically speed up their workflow.


New release: gadicc:ecmascript-hot@0.0.10-rc.3

  • Works with Meteor 1.3-rc.3.

@tomRedox, this Meteor release fixes the Windows support :slight_smile:

@mordrax, always appreciate your updates :slight_smile: As for webpack:webpack, it looks totally awesome tbh, especially the new release. Was tempted to abandon this and just use that :wink: But for a few of my projects, strict compatibility with native Meteor is a requirement. So I guess it depends on the use case.

My package kind of cheats w.r.t. stateless components, I did my own quick fix while waiting for community support to stabilize. That means PR#85 when it’s ready - it’s a similar approach to what I’m using, which still has issues (I made a note about in the README), but it’s better than not having it imho. Gaearon has some more stable long term plans, but this will fill the gap until then.


For those of us who are not very familiar with webpack, hot reloading, code splitting, “native” meteor support for all these etc, could someone please:

  1. Explain what webpack:webpack does and why we should use it
  2. Explain what gadicc:ecmascript-hot does and why we should use it
  3. How does one compare to the other and what are possible reasons for a dev to choose one over the other and if those reasons would change per project

Obviously, this is a cross-post on two very related topics, so please bear with me as this is not spam but a genuine call for some explanation in layman terms.

Thanks :slight_smile:


I’ll reply to that in What is hot reloading and code splitting; webpack:webpack vs ecmascript-hot.


Hi @gadicc, I tried the rc.3 version, but rc.3 itself is running super slow for me (the meteor code, not your module), so I’ve switched back to beta.12.

I’m not actually having any luck getting this working with beta 12 though, I’m editing jsx and it’s still causing a full rebuild. I’ve done the following:

  • npm install --save react-transform-hmr
  • Edited .meteor/packages and replaced ecmascript with gadicc:ecmascript-hot@0.0.7-beta.12

Did I miss something? I think I remember why I tried an earlier version that there you had messages showing in the terminal? I’m not seeing those now.


Are these stateless components? React components are easy to detect because they extend from React.Component, however stateless components are just plain js functions so gadicc does some funky regex pattern matching. Your stateless function needs to be in these formats for the hot loader to work on it.

const MyComponent = ({prop1, prop2}) => (
  ... jsx ...

const MyComponent = ({prop1, prop2}) => {
  // must include /return\s+\(\s*\</
  // i.e. "return", whitespace, "(", optional whitespace, "<"
  return ( <JSX /> );

If all else fails, show us your code.


@tomRedox, yeah, I turned off the console logs, it was a bit annoying :> But! You should be seeing it with that old 0.0.7-beta.12 release though! It used to look like:

=> App running at: http://localhost:5800/     
[gadicc:hot] Creating a bundle for 1 change file(s)...
=> Client modified -- refreshing

As @mordrax said (thanks!), we’re fairly strict on stateless components. Is that a possibility? But yes, you should get that log on the console, and quite uncertain how it’s possible to not get that when using that release of the package… if your source is public I’m happy to take a look.

Also, your file has the extension .jsx and has ‘client’ but not ‘test’ somewhere in the path? Actually, I just noticed this test has a mistake in it, so I guess even if you’re working on a file client called client/hmr_test.jsx it won’t be included.


New release: gadicc:ecmascript-hot@0.0.11-rc.4

  • Works with Meteor 1.3-rc.4.


Just a quick note that the above release still works with Meteor 1.3-rc.6, since there were no changes to any of the core packages we rely on. This could be the final rc before Meteor 1.3 stable. :tada:


I have some false positives and I am not sure how to debug them. Here the first one (my example) on 1.3-rc.6 (and 4):

   While processing files with gadicc:ecmascript-hot (for target web.browser):
   imports/_screens/_shared/_auth.jsx:5:11: Unexpected token (5:11)

   While processing files with gadicc:ecmascript-hot (for target
   imports/_screens/_shared/_auth.jsx:5:11: Unexpected token (5:11)

Okay, confusing the parser with

const /* */ _auth = ({ content, link }) => (

seems to work. Also at some other places.

However, the app does not render. Browser console error:

gadicc_hot.js:198 Uncaught TypeError: modulesRuntime.meteorInstall._expose is not a function

gadicc_ecmascript-hot.js:7 Uncaught TypeError: Cannot read property 'hot' of undefined

global-imports.js:40 Uncaught TypeError: Cannot read property 'hot' of undefined

modules.js:101872 Uncaught Error: locals[0] does not appear to be a `module` object with Hot Module replacement API enabled. You should disable react-transform-hmr in production by using `env` section in Babel configuration. See the example in README:

Okay, that could have been a browser cache issue. A cache reload helped. However, if I change something inside a react component (the whole app structure follows the imports/ structure) no HMR is visible.

I am not sure if I do something wrong - followed the by word. If you care to see yourself, simply use the and try to add your package. I guess file changes are also not properly picked up in the imports folder. I guess I’ll move back to webpack for now.


Ah, if there’s an issue with the imports folder @gadicc then that would explain the issues I was having too as we are also using that structure.


Hey, thanks, I released a v0.0.12-rc.8 (works with Meteor’s rc.4-rc.8) which fixes the Unexpected token error. It wasn’t a false positive, there was a regex was munging the newline before the function, joining it onto the comment on the line before. That’s fixed now, and a few other small things.

Regarding imports dir, it’s a little more complicated. Anytime you make a change in there, the Meteor server reloads too, killing the package before it can send the update through.

There is a workaround, which may or may not be acceptable, and that’s to still put a client subdirectory inside your imports dir. That seems to be enough to satisfy Meteor, which seems to rely more on paths than the import tree to figure out what to reload.

@dinos, I tested this on your app and it works great. It does require some unfortunate restructuring though :frowning: As I said, a workaround that may or may not be acceptable for your project.

I’ll have to think if there are any ways to get around this in the longer term.

@tomRedox as above.


@gadicc, that all makes sense now. I had all my GUI code in a /imports/ui directory. I’ve just renamed that to /import/client and it’s all working :smiley:, thanks for the help and all the hard work.

I’m still using Meteor beta.12 because I’m experiencing slow rebuilds in rc3-rc8, so I’m using gadicc:ecmascript-hot@0.0.7-beta.12 for the time being.


Thank you! This was valuable information! I really don’t want to hard separate client code anymore.

Where is this limitation coming from in the build process? I want to add a ticket to meteors 1.3 track

PS: I assume you simply put components and screens into a client folder


I added a bug ticket. We need to get away from the client/server split up.


Thanks, @dinos! I never really tracked it down in the code, just noticed the behaviour.

Yes, I was too lazy to adjust the server links too, so just copied all the folders into the client folder and adjusted the client/style entry files. Obviously if you wanted to go this route you’d need to restructure properly, but for testing purposes this was good for me :>


Yeah, since this todo is an example of a … not very trivial large app… with a team… I currently investigate if its enough to have components and screens under a clients/ folder. But as beniot, would be grade if you could chip in on the issue above at metoer and stress, that the current watcher behavior feels like a hack.


Has anyone had good luck enabling decorators using this?

I tried by adding the transform-decorators plugin but it always complains about adding the decorator plugin before the class plugin!

While processing files with gadicc:ecmascript-hot (for target web.browser):
framework/client/components/baseComponent.jsx:10:4: /framework/client/components/baseComponent.jsx: Method has decorators, put the decorator plugin before the classes one.