The latest release of meteor-react-hotloader (v0.0.11-rc.2 released 2016-03-18) allows the use of a custom .babelrc in your project root to extend Babel with additional presets and plugins, like jsx-control-statements. Itās essentially an early look at what weāll get officially in post-1.3.
See the README for installation instructions. If you donāt want the react hotloading, you can simply remove the babel-plugin-react-transform section from your .babelrc.
Note, if you already have a .babelrc in your project root, currently Meteor is ignoring it. So when it suddenly works, it could break your project. e.g. thereās a plugin in manta-sample-blog-app thatās used for testing outside of Meteor but breaks the real Meteor build (tracking here).
Iām interested in some early feedback and to see what people do with this.
Just FYI, you might want to make it possible to have separate .babelrc for the client and server. For instance, if people are doing React with the hot loader plugin and using React SSR, there have to be separate configs because the hot loader plugin would break the React SSR.
Unfortunately, I donāt know if thereās a convention. I know I and some other Webpack users put the babel configuration directly into the babel-loader part of the Webpack configs for server and client. But while Babel can process "env": {"development": {...}} in .babelrc, I donāt know if it supports anything analogous for build targets.
In any case, it at least suffices to have completely separate server/.babelrc and client/.babelrc; Iām not sure whether thereās a foolproof way to merge them into the main file, it might be risky.
I just searched and found something straight from the horseās mouth:
github-migration added a comment.Via Conduit Ā· Jul 10 2015, 7:37 PM
Comment originaly made by mpal9000 on 2015-07-10 14:37:30
I would like to use combinations of BABEL_ENV and another āBABEL_TARGETā variable.
sebmck added a comment.Via Conduit Ā· Jul 10 2015, 7:39 PM
Iām confused, why? Babel isnāt a build system and the options currently provided are more than adequate for basic use-cases. If you need anything more sophisticated then Iād recommend using something like Gulp or Grunt.
So it sounds like Babel doesnāt want a standard for handling build targets orthogonal to development/production to live in Babel, at least, and prefer to leave that to other build tools.
Though this may be more of a problem for Webpack users than Meteor as we rely on a lot of process.env.NODE_ENV === 'production' code getting uglified away (including within React libraries)
@jedwards, can you try gadicc:ecmascript-hot@1.3.0-2 after reading the upgrade notes in the History.md and new sample .babelrc files at the end of the README and see if this solves this for you?
As youāll see, in the end, I decided to allow the server/client files to extend the root .babelrc. Itās optional, but it is the recommended pattern, since most of the presets/plugins will be relevant for both targets.
Of course, with that hurdle out the way, this still doesnāt work with FlowRouter SSR, because, changes to files outside of client will cause a server reload, which will kill react-hotloader before it can send the update. Iāll track this in https://github.com/gadicc/meteor-react-hotloader/issues/17#issuecomment-203523367.
I have the corresponding packages installed in my node_modules (babel-preset-es2015, babel-preset-stage-0, etc), however, they donāt seem to be loading.
The specific transform I need are class properties, if I add the class properties transform plugin to plugins list, it works.
@billyvg, I think youāre rightā¦ over here I have meteor first; Iām using stage-0 and class properties are working for me.
This is going to be an ongoing problem. In the latest release (that youāre using), I no longer force .babelrc to contain meteor (oops, forgot to mention that in the History).
I think long term, we should try get rid of the meteor preset and just have a default .babelrc with the same settings, using the more well known presets.
Well, I might have given the impression that I use gadicc:ecmascript-hot, but really I just use Webpack with Meteor. I was just letting you know what users of your package might eventually want.
I didnāt actually mention it, but some two weeks ago I completely separated the HMR and babelrc support, in anticipation of the official Meteor babelrc support which I think is expected soon. But until that happens, you can just replace ecmascript with gadicc:ecmascript-babelrc for a babelrc-only solution (without HMR).
Perhaps more importantly I should mention (for those that missed it) that official support is available in the 1.3.3 betas Worth checking out ASAP and giving any feedback, 1.4 is ready and lined up for right after the 1.3.3 release. More info in Please help test the latest 1.3.3 beta release!.
Yes, Iāll support separate configs in a future release.
Worth checking out ASAP and giving any feedback, 1.4 is ready and lined up for right after the 1.3.3 release. More info in