This looks really cool. Have been tearing my hair out with slow reload times on the client side. But, Iām a little confused with this step of the installation:
Symlink babel-compiler-hot, ecmascript-hot, hot and modules-runtime (#6) to your appās packages dir.
Can you provide a little more clarity? Should I be doing step 1 (the git clone) in the root of my project directory?
Getting this error while trying to load - While loading plugin 'compile-ecmascript-hot' from package 'gadicc:ecmascript-hot': module.js:338:15: Cannot find module 'mongodb'
No I realized that after I already finished publishing. See the project README. The one in Atmosphere will be updated on my next publish, I didnāt want to bump versions and republish just to update the README thereā¦
So yeah no need for the git clone anymore. You can indeed do meteor remove ecmascript and then meteor add gadicc:ecmascript-hot@0.0.1-modules.7, or just reflect this in .meteor/packages.
I also see you submitted https://github.com/benjamn/install/pull/6, which I would like to avoid if thereās any other way to do it, but Iām sure we can figure something out.
Yes, please do share your thoughts. I had planned to discuss the way forward with you after a 1.3.0 final came, once things have calmed down a bit. If youād like to do so before, let me know your preferred medium (we could open an issue on meteor/meteor to track the various subissues involved, etc).
As per the README, this current solution is āhacky by designā (which has been quite liberating). Itās also not a full HMR implementation, but just the bare minimum needed for the react hotloading to work. However, if youād like this to serve as the basis for something official, I can gradually move to something more structured where possible (e.g. full HMR runtime on the client, with tests, etc; modifying the build process in the āright wayā might be beyond me though).
Hope people have been enjoying this! Unfortunately since Iām using pre-release version numbering I canāt track downloads on Atmosphere.
Iāll also be a bit more pro-active at announcing version updates here, since a few annoying things got fixed recently. The current version is gadicc:ecmascript-hot@v0.0.3-modules.7 and you can see the changelog in the 2nd post of this thread or on github.
The two most important recent changes are better module resolution (we didnāt support root and some relative paths until now), and an automatic full client refresh for cases we canāt handle (so no need to manually restart Meteor, which was annoying). You can also trigger this by hand by just typing hot.reload() in the console now, if desired.
Top priority moving forward is better recognition of stateless components, and cases where hotloads fail when they shouldnāt (and we need your help here to report them). A longer term goal is to provide full HMR support (not just for react), which will allow redux and other hotloading too.
But most important is feedback. Is this working well for you? When isnāt it? Reporting issues on github is the only way annoying things will get fixed.
P.S. Iām away for a few days again and am travelling after, but Iāll find time to squeeze in small fixes here and there.
Edit your .meteor/packages and replace ecmascript with gadicc:ecmascript-hot@0.0.2-modules.7 (donāt forget to set it back before a production deploy!)
How do you propose handling that if weāre using the Atmosphere package? Must we āmeteor remove gadicc:hotā before doing our Mup deploys?
@jasongrishkoff, yeah sorry, you no longer need gadicc:hotin your .meteor/packages file. Since the Atmosphere release, gadicc:ecmascript-hot implies gadicc:hot too, to make for a super simple replacement.
I too recommend just toggling the comments like @mordrax suggested, before deploy. If you prefer using the meteor CLI, thatās fine too, but then you should also meteor add ecmascript after removing ecmascript-hot. Hopefully in the future we can come up with a good way to avoid the need for this.
Last note, looks like I didnāt update the README properly, the current latest version is indeed 0.0.3.
I have not tested it so I donāt know if it works but maybe you could use a condition on process.env.NODE_ENV on the gadicc:ecmascript-hotpackage.js file?
I think it is. Meteor relies on package.js to build the package to be published, making conditional logic problematic. I know we used tricks like this often in the past but as far as I know package bundling is handled differently for a while now.
Had to interrupt my flow and share this. (tl;dr - This package is the sh!ts, why are you not using it already in 1.3?)
So I was doing some massive refactoring because due to some brain-spasm, I had introduced ES6 classes into my redux state which was causing all sorts of refresh issues as I modified internal properties.
JS being the unfriendly, untyped monster it was caused everything to break left right and center as I jiggled around my states to normalize them, reordered my reducers, removed classes etc etcā¦ My chrome dev console was throwing errors, Max stack limit reached, cannot hot reload x.js and others. But I persevered knowing that my goal was within sight.
Lastly, I came to hooking up the init state so I could test by hitting any route on a refresh:
let areas = generateAreas();
cotwStore.dispatch({type: "INIT_AREAS", areas});
The moment I typed the last ;, hit <enter> and Ctrl+S, my browser which had constantly been blank and flashing errors in the console suddenly sprang into life and my game map was BACK!
I lost the plot.
The workflow with hotloading has been amazing. It almost instantly refreshes react component changes and also does a full refresh on all other file changes. I donāt know why but a full refresh with hot loading is also faster, taking on average ~2sec with the error appearing in the console.
Normally, Iād be waiting 5-10 secs for meteor to build on each compile/debug/test loop.
W20160218-15:34:03.513(-8)? (STDERR)
W20160218-15:34:03.514(-8)? (STDERR) /Users/dpnewman/.meteor/packages/meteor-tool/.1.1.13-modules.7.ip1bjg++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:245
W20160218-15:34:03.515(-8)? (STDERR) throw(ex);
W20160218-15:34:03.515(-8)? (STDERR) ^
W20160218-15:34:03.602(-8)? (STDERR) 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
W20160218-15:34:03.602(-8)? (STDERR) at proxyReactComponents (/Users/dpnewman/Meteor/haven-app/.meteor/local/build/programs/server/packages/modules.js:21750:11)
W20160218-15:34:03.602(-8)? (STDERR) at meteorInstall.both.lib.authorizeForRole.jsx (/Users/dpnewman/Meteor/haven-app/.meteor/local/build/programs/server/app/app.js:59:59)
W20160218-15:34:03.603(-8)? (STDERR) at fileEvaluate (/Users/dpnewman/Meteor/haven-app/.meteor/local/build/programs/server/packages/modules-runtime.js:219:9)
W20160218-15:34:03.603(-8)? (STDERR) at require (/Users/dpnewman/Meteor/haven-app/.meteor/local/build/programs/server/packages/modules-runtime.js:92:20)
W20160218-15:34:03.603(-8)? (STDERR) at /Users/dpnewman/Meteor/haven-app/.meteor/local/build/programs/server/app/app.js:12405:1
W20160218-15:34:03.603(-8)? (STDERR) at /Users/dpnewman/Meteor/haven-app/.meteor/local/build/programs/server/boot.js:242:10
W20160218-15:34:03.603(-8)? (STDERR) at Array.forEach (native)
W20160218-15:34:03.603(-8)? (STDERR) at Function._.each._.forEach (/Users/dpnewman/.meteor/packages/meteor-tool/.1.1.13-modules.7.ip1bjg++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/underscore/underscore.js:79:11)
W20160218-15:34:03.603(-8)? (STDERR) at /Users/dpnewman/Meteor/haven-app/.meteor/local/build/programs/server/boot.js:137:5
=> Exited with code: 8