Tag Archives: babel

Upgrading to Babel 6 the awesome way

Upgrading to Babel 6.x can’t be that hard, right? Well, it can if you’re like me who wants maximum modularization. But it isn’t, really.

I love modularization. And making an effort to do so can really significantly reduce your own module size, if not where, when it counts. So yes, npm may not now dedupe by default (whether or not it does when you read this, then awesome) but if a module author decides to do so, then all’s good, right? I especially love lodash and how it’s divided into modules. That’s kinda what Babel does now.

So, how do we upgrade to Babel the awesome way?

Okay, first uninstall the babel package if you still have it: npm un -sD babel —we won’t need it anymore. If you have it installed globally, you might want to uninstall that too.

Next, install either babel-cli or babel-core depending on what you’re using. babel-cli is what you need when you need the CLI. (Good job, Sherlock) For a refresher or if you don’t know already, the CLI programs that come with it are babel, that transforms your code, and babel-node, that’s like a node.js proxy with both a runner and a REPL. Or install both if you need to. They’re modular anyway. I’m not much of a fan of require hooks, but if you swing that way, I can’t stop you.

Okay, at this point if you’re a n00b or a conformist you would now pick one of the presets to support ES2015 functionality, in which case I’m wondering why you’re reading this blog post when you could just go over to the website and follow the instructions. If you aren’t, you may continue reading.

Next, decide on the plugins you wish to include. Now here’s the trick to the awesome. If you’re not yet using node v5 or at least node v4 then you’re being out of the loop. The thing is, ECMAScript 2015 (say what??) has been released last June. So now we can use most of its features really. Support is flaky here and there but most of the usable ones have already arrived in various JavaScript environments. Now, I might be being a bad influence here but I’m only planning to support V8, but you can be better and support, I don’t know, SpiderMonkey? IE?

Anyway, if you’re like me, the point is if I see a feature is already supported by node and Chrome, I won’t have to transform it, right? So just pick plugins that you actually need. kangax’ compat tables might help. Basically, by doing this I have drastically reduced the number of plugins I needed for my code.

For module authors: If you’re not much of a polyfilling fan and would like to drop support for environments only compatible with ES5 or lower, consider not using the babel-runtime module and the babel-plugin-transform-runtime plugin anymore. Basically what it does is it ponyfills your code environment with babel-runtime which contains the JavaScript globals and functions you’ll need in an ES2015 environment, as well as regenerator, which works with generator functions. You’d then include babel-runtime to your dependencies. Not that I’m not a fan of core-js (it is seriously awesome) but native is better if it exists already.

Here’s my package.json for one of my projects using Babel:

{
  ...
  "devDependencies": {
    "babel-cli": "^6.1.2",
    "babel-plugin-transform-async-to-generator": "^6.0.14",
    "babel-plugin-transform-es2015-destructuring": "^6.0.18",
    "babel-plugin-transform-es2015-modules-commonjs": "^6.1.3",
    "babel-plugin-transform-es2015-parameters": "^6.0.18",
    "babel-plugin-transform-strict-mode": "^6.1.2",
    "babelify": "^6.3.0",
    "browserify": "^10.1.0",
    ...
  },
  "babel": {
    "plugins": [
      "transform-es2015-destructuring",
      "transform-async-to-generator",
      "transform-strict-mode",
      "transform-es2015-parameters",
      "transform-es2015-modules-commonjs"
    ]
  },
}

That’s just 5! Compare that to how many plugins I get when I actually used a preset.

You may ask: what’s with destructuring? Well, this project specifically has a lot of entry points and I don’t want to risk breaking anything, at least for now. If you didn’t already know, node already has support for destructuring via the --harmony_destructuring flag. If you’re still reading, you should definitely check out the node.js docs and see if you can further reduce the number of plugins you need simply by turning on a runtime flag. As for this specific project, it might be fine since it’s run on the server side, the catch is that it has front-end code. (Check out babelify!) And as of the time of writing, Chrome still does not have destructuring support (by default, anyway) hence the decision I made.

strict-mode is there because apparently I’m too lazy to add 'use strict' on top of all of the code. As you might have seen in kangax’ compat tables, V8 still doesn’t support some ES2015 features without seeing it.

Also, if anybody’s noticed: I put my babel config in my package.json file. This is just a personal preference. Personally, I don’t want so many files cluttering my project. So yeah, that’s why I don’t like Visual Studio Code.

If anyone has been reading my blog recently, this is the same project I had some trouble on.

Here’s one from a super-secret project that a reader has decided to bug me about:

{
  ...
  "devDependencies": {
    "babel-cli": "^6.1.1",
    "babel-core": "^6.1.2",
    "babel-plugin-transform-es2015-destructuring": "^6.0.18",
    "mocha": "^2.0.1"
    ...
  },
  "babel": {
    "plugins": [
      "transform-es2015-destructuring"
    ]
  }
}

Simple, right? Only one plugin. Here I have both babel-cli and babel-core installed because I use babel-cli for transforming my code and babel-core to test with Mocha.

TL;DR just read the bolded phrases.

Update: If you plan to support only node v4 and up and presets are totally fine with you then there’s this preset for node v4.