Meteor can’t find gadicc:ecmascript-hot@0.0.11-rc.2 when I try to install it.
The Github repo looks like the latest version is gadicc:ecmascript-hot@0.0.9-rc.2 and that is the one I was able to install. Is it suppoed to have been published already?
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 
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 
@mordrax, always appreciate your updates As for webpack:webpack, it looks totally awesome tbh, especially the new release. Was tempted to abandon this and just use that 
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.
1 Like
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:
- Explain what webpack:webpack does and why we should use it
- Explain what gadicc:ecmascript-hot does and why we should use it
- 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
I’ll reply to that in What is hot reloading and code splitting; webpack:webpack vs ecmascript-hot.
2 Likes
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
ecmascriptwithgadicc: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.
1 Like
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. 
3 Likes
I have some false positives and I am not sure how to debug them. Here the first one (my github.com/d1no/todos 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
os.osx.x86_64):
imports/_screens/_shared/_auth.jsx:5:11: Unexpected token (5:11)
EDIT:
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: https://github.com/gaearon/react-transform-hmr
EDIT2:
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 readme.md by word. If you care to see yourself, simply use the github.com/d1no/todos 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 
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.
2 Likes
@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 
, 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.
1 Like
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
1 Like
I added a bug ticket. We need to get away from the client/server split up.
1 Like
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.