Don't use Babel transpilers when debugging an application

To clarify, I use many Babel plugins when developing an application (I have written a handful of Babel plugins to improve DX). Furthermore, I transpile my code using heavy presets such as es2015 and various other stage-X transpilations before deploying the application. Heck, I even use a Babel plugin to overload an existing syntax to enable function composition. However, I don't use any transpilations when debugging an issue.

I can afford not using Babel transpilers in my development environment because I know in advance about the features of the environment in which the code is going to run. Here is an example of the .babelrc configuration I am using in the current project:

{
  "env": {
    "test": {
      "plugins": [
        "istanbul",
        "transform-export-default-name",
        "transform-es2015-modules-commonjs",
        "transform-async-to-generator",
        "transform-flow-strip-types",
        "transform-es2015-destructuring",
        "transform-es2015-parameters",
        [
          "transform-object-rest-spread",
          {
            "useBuiltIns": true
          }
        ],
        "transform-class-properties"
      ],
      "sourceMaps": "inline"
    },
    "development": {
      "plugins": [
        "transform-export-default-name",
        "transform-flow-strip-types",
        [
          "transform-object-rest-spread",
          {
            "useBuiltIns": true
          }
        ]
      ]
    },
    "production-mainstream": {
      "plugins": [
        "closure-elimination",
        "transform-flow-strip-types",
        "transform-async-to-generator",
        "transform-es2015-destructuring",
        "transform-es2015-parameters",
        [
          "transform-object-rest-spread",
          {
            "useBuiltIns": true
          }
        ],
        "transform-class-properties",
        "transform-es2015-classes"
      ]
    },
    "production-legacy": {
      "plugins": [
        "closure-elimination",
        "transform-flow-strip-types"
      ],
      "presets": [
        "es2015",
        "stage-0"
      ]
    }
  }
}

In the above example, I am using NODE_ENV=development configuration to run Babel with the least possible transpilations required for the code to work in my browser (Google Chrome 57 has 97% ES6 support).

The main benefits of this approach are:

• You don't rely on source maps. (There are issues related to using sourcemaps.)
• You are able to set breakpoints and evaluate code at the breakpoints. (If you ever had to inspected a heavily transpiled code, chances are that you ran into issues of variable names changing or not being able to set a breakpoint at the script execution time.)
• The overall code bundling and execution time is faster.

A simple tip that saves me pains when debugging a code base, yet I see few development setups that utilise it.

Ingvar Stepanyan reminded me about babel-preset-env. It is a Babel preset that automatically determines the required Babel plugins based on the provided environment criteria (e.g. Chrome 54, current node version, etc). It has reached v1.0.0. Think of it as a autoprefixer in your continuos-delivery setup.