Hi @gadicc
I have a hard time to figure out how to get this work. I am completely lost between the two .babelrc the npm packages to install and the version of ecmascript-hot to use.
I have a lot of error at compile time: /Users/vikti/.meteor/packages/gadicc_ecmascript-hot/.1.3.1_1.17g1xzl++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor-babel/node_modules/babel-core/lib/transformation/file/options/option-manager.js:179:17: Unknown plugin "transform-decorators-legacy" specified in "/Users/vikti/dev/wizar-guide/.babelrc" at 0, attempted to resolve relative to "/Users/vikti/dev/wizar-guide" at /Users/vikti/.meteor/packages/gadicc_ecmascript-hot/.1.3.1_1.17g1xzl++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor-babel/node_modules/babel-core/lib/transformation/file/options/option-manager.js:179:17 at Array.map (native) at Function.normalisePlugins (/Users/vikti/.meteor/packages/gadicc_ecmascript-hot/.1.3.1_1.17g1xzl++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor-babel/node_modules/babel-core/lib/transformation/file/options/option-manager.js:155:20) at OptionManager.mergeOptions (/Users/vikti/.meteor/packages/gadicc_ecmascript-hot/.1.3.1_1.17g1xzl++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor-babel/node_modules/babel-core/lib/transformation/file/options/option-manager.js:277:36) at OptionManager.addConfig (/Users/vikti/.meteor/packages/gadicc_ecmascript-hot/.1.3.1_1.17g1xzl++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor-babel/node_modules/babel-core/lib/transformation/file/options/option-manager.js:207:10) at OptionManager.mergeOptions (/Users/vikti/.meteor/packages/gadicc_ecmascript-hot/.1.3.1_1.17g1xzl++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor-babel/node_modules/babel-core/lib/transformation/file/options/option-manager.js:284:14) at OptionManager.init (/Users/vikti/.meteor/packages/gadicc_ecmascript-hot/.1.3.1_1.17g1xzl++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor-babel/node_modules/babel-core/lib/transformation/file/options/option-manager.js:465:10) at File.initOptions (/Users/vikti/.meteor/packages/gadicc_ecmascript-hot/.1.3.1_1.17g1xzl++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor-babel/node_modules/babel-core/lib/transformation/file/index.js:194:75) at new File (/Users/vikti/.meteor/packages/gadicc_ecmascript-hot/.1.3.1_1.17g1xzl++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor-babel/node_modules/babel-core/lib/transformation/file/index.js:123:22) at Pipeline.transformFromAst (/Users/vikti/.meteor/packages/gadicc_ecmascript-hot/.1.3.1_1.17g1xzl++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor-babel/node_modules/babel-core/lib/transformation/pipeline.js:67:16) at /Users/vikti/.meteor/packages/gadicc_ecmascript-hot/.1.3.1_1.17g1xzl++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor-babel/index.js:53:34 at Cache.Cp.get (/Users/vikti/.meteor/packages/gadicc_ecmascript-hot/.1.3.1_1.17g1xzl++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor-babel/cache.js:94:19) at Object.compile (/Users/vikti/.meteor/packages/gadicc_ecmascript-hot/.1.3.1_1.17g1xzl++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor-babel/index.js:43:23) at Object.Babel.compile (packages/gadicc_babel-compiler-hot.js:447:24) at packages/gadicc_babel-compiler-hot.js:543:24 at Function.time (/tools/tool-env/profile.js:305:10) at profile (packages/gadicc_babel-compiler-hot.js:604:20) at packages/gadicc_babel-compiler-hot.js:542:22 at Array.forEach (native) at BabelCompiler.BCp.processFilesForTarget (packages/gadicc_babel-compiler-hot.js:491:14)
Hey @vitki, glad you managed to sort this out. Iāve added clearer instructions and troubleshooting steps about plugins & presets to the README to help others too. Re your other questions (which might help others):
What version to use when I do meteor add gadicc:ecmascript-hot@xxx?
You can leave out the @xxx part now. This was only needed in the past before Meteor 1.3 was released. So just leave this out and it will add our current stable release, and updates will come in via meteor update.
The exception is experimental releases and pre-releases. For that you should use whatever we tell you to put there for that specific release
What to put in the various .babelrc files, and what to npm install?
There are samples at the bottom of the README for a basic setup (and as you saw, the first long npm install in the āhow to useā instructions). From that initial step, you can add any extra plugins/presets you need, to the .babelrc, and via npm install. There are clearer instructions for this now at the bottom of the README.
I will also use Typescript. Is this compatible?
Unfortunately I have no experience with typescript, I hope someone else can help out here. If all typescript needs are babel plugins, it should work fine.
P.S. Instead of adding packages directly to your package.json by hand, itās easier to do it via npm install --save (or --save-dev for babel plugins). This will download the latest version and add it to your package.json in a single step.
New experimental release: gadicc:ecmascript-hot@=1.3.2-fast.13
Following up my post 11 days ago, there has been a lot of progress on the fast and faster branches of the project. As usual, Iām using the code every day in my own work and itās become pretty stable; additionally, with a lot of help from community reports on github, various edge cases have been fixed too. Iād especially like to thank @clayne for the many hours heās spent this week hunting down bugs and submitting the first two PRs to the project.
Please try this release and report back. Although itās still marked as āexperimentalā, and a few issues are still open on github, barring any new major bug discoveries, this code will hopefully be released as stable next weekend. You can do this by specifying the exact version with @=, i.e.
meteor add gadicc:ecmascript-hot@=1.3.2-fast.13
Changes
Works with Meteor 1.3.2 and 1.3.2.1.
Major speed improvements, especially when you have a lot of non-client-only files in your project.
Now works with meteor test and meteor test-packages.
Various other fixes, resiliency and improved help when debugging, as detailed in the History.md.
Thanks for the edit, though I fear this particular release is not for me:
fs.js:1063 throw errnoException(process._errno, 'watch'); ^ Error: watch ENOENT at errnoException (fs.js:1031:11) at FSWatcher.start (fs.js:1063:11) at Object.fs.watch (fs.js:1088:11) at Object.handlers.fileData (C:\Users\johan\AppData\Local\.meteor\packages\gadicc_ecmascript-hot\1.3.2-fast.11\plugin.compile-ecmascript-hot.os\npm\node_modules\meteor\gadicc_babel-compiler-hot\node_modules\meteor-hotload-accelerator\lib\accelerator.js:118:8) at process.handlers.close.process.send.type (C:\Users\johan\AppData\Local\.meteor\packages\gadicc_ecmascript-hot\1.3.2-fast.11\plugin.compile-ecmascript-hot.os\npm\node_modules\meteor\gadicc_babel-compiler-hot\node_modules\meteor-hotload-accelerator\lib\accelerator.js:60:52) at process.emit (events.js:98:17) at handleMessage (child_process.js:322:10) at Pipe.channel.onread (child_process.js:349:11)
Can you try meteor add gadicc:ecmascript-hot@=1.3.2-fast.12 ? It fixes what I think/hope is wrong on Windows, but failing that, Iāll have to setup a windows VM here or try find some contributors running Windows.
Sorry all to those who already upgraded, a small fix got left out of the releaseā¦ please rather use ecmascript-hot@1.3.2-fast.13, Iāve amended the install instructions above too. This doesnāt affect the still remaining bug for Windows users.
Mmm, something similar was reported in https://github.com/gadicc/meteor-react-hotloader/issues/47 but I canāt reproduce. Can you confirm with the latest versions of Meteor and fast? Meteor 1.3.2.2 and gadicc:ecmascript-hot@1.3.2-fast.13.
Im trying to use this with MantraJS but really dont know where to put the
import { AppContainer } from āreact-hot-loaderā; as everything is loader by react-mounter.
The same for meā¦ Previously I have passed <Layout content={ Content } /> from main container render method to react-mounter. After updating ecmascript-hot to 1.3.2 I have changed the main container render method to return to <AppContainer><Layout content={ Content } /></AppContainer>. I feel that if (module.hot) { ... } should be somewhere it the render(), however I do not catch how to do it @gadicc, please advice.
@dortega, @priezz, yes, unfortuntely it isnāt obvious with manta what to do, so I forked mantra-sample-blog-app and added the necessary hotloading stuff. Most important is this changeset which shows all the changes needed from the original (and for those that want it, itās possible to just clone clone gadicc/mantra-sample-blog-app-hot too).
For everyone else, just to be clear, this is for the upcoming ārefactorā release of meteor-hmr, which uses the upcoming React Hot Loader v3 (currently in beta).
@gadicc, thanks for that. Do I understand right that I can use the updated hot-reload functionality only passing URLs of container modules to the routing routine (to be able to require them later), but not the containers themselves? I understand, that it is not considered as the good coding style, but I suppose there could be a case when several top-level containers are described in a single .jsx file. Passing containersā names to the router will help in this case, but the whole construction will be too weird.
Sure. Iām not 100% sure I understood correctly. But I think these are the pertinent issues:
Hot updates flow up the tree to an ancestor that can accept them. So if Routes.jsx > Container > X > Y and Y is updated, that will still work fine.
require('path') is near identical to import X from 'path'. Currently Meteor transpiles import's to require()'s anyway via babel. Thereās no way around this - but just for now. In Webpack 2 for example, imports work with hot loading, and Meteor will get this too in the future, Iām sure.
Module exports are cachedā¦ so require('somePath') multiple times is cheap. We could require() earlier and give some local variable to the action() methods, but I think this would unnecessarily complicate what we are actually trying to achieve. But you could do this if youāre relying on passing a variable name around (e.g. thereās a plugin for react that figures out the variable name and passes it back to React).
Having written all that I think maybe the latest sentence is what you were getting at but if I missed anything please let me know Heading out now but will be back later.
Looks like an issue on Windows. Will see what we can do about this. Thanks for reporting.