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.
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