Babel

Planning for 7.0

Tue, 12 Sep 2017 10:00:00 +0000

If you didn’t know already, we’re planning on releasing a 7.0 version soon 🙌 ! Work on it actually started back in February, when I just wanted to make a release to drop Node 0.10/0.12 support and remove babel-runtime and various other code. And since then, we’ve done releases up to alpha.20.

We’re going to update this post throughout the beta releases

Since we’re still just a volunteer project, it’s been difficult for most of the team to stay focused and motivated to make all these changes and continue to maintain a project that so many companies, bootcamps, and tools rely on so much. But in the meantime we’ve made a lot of progress: weekly meetings/notes, participating as invited guests at TC39 for the last few meetings, facilitating in both RGSoC and GSoC, and creating an Open Collective.

Upgrading

Upgrading for most projects should be as simple as updating your package.json deps to 7.0.0-beta.0. For the whole time we’ve been working on 7.0, we’ve been using it in Babel itself (so meta) and at my workplace at Behance.

We will be pinning all dependencies to exact versions until the official release.

{
  "devDependencies": {
    "babel-cli": "7.0.0-beta.0"
  }
}

Specific packages:

babel packages in the monorepo should all be >= 7.0.0-beta.0
babel-preset-env should be at least 2.0.0-beta.0
babel-eslint can be >= 8.0.0
babel-loader should be >= 7.0.0 (out of beta since it uses babel-core as a peerDependency)
grunt-babel can be >= 7.0.0
gulp-babel can be >= 7.0.0
rollup-plugin-babel can be >= 3.0.2

Please check out our upgrade guide and other guide specifically for tool authors which we will also be updating as necessary.

I’d like to go over some notable changes for our first beta release (it’s still a lot smaller in scope in terms of breaking changes than the previous 6.0 release).

Re-iterating Project Goals

Before we go into that, I just want to repeat again what the purpose of Babel is.

Since Babel has been renamed from 6to5, browsers have been implementing more of the spec and users are more comfortable with using the latest syntax/build tooling. It shouldn’t be surprisingly however that Babel’s goals haven’t changed much.

Our two goals are hand in hand:

Help developers transform new syntax into backwards compatible code (abstract browser support away)
Be a bridge to help TC39 get feedback on new ECMAScript proposals and for the community to have a say in the future of the language.

Thus, I think it’s an understatement to say that Babel is a vital part of the JavaScript community (almost 10 million downloads a month of babel-core) and sorely needs its support. (The only talks I’ve tried to give are about this point: JSConf EU, React Rally, TC39). I said recently: “What happens if Babel dies”? What happens when the current group of people interested in this project get bored/burned out/move on to other things? (What if it’s already happened?). Are we going to do something about it? I don’t want to just ask you to help us, you already are us as users of the project.

Ok then, let’s talk about some changes!

#4315 Drop support for unmaintained Node versions: 0.10, 0.12, 5

Progress in OSS projects often comes at the cost of upgrading for its users. Because of this, we’ve always been hesitant in making the choice to introduce a major version bump/breaking changes. By dropping unsupported versions of Node, we can not only make a number of improvements to the codebase, but also upgrade dependencies and tools (ESLint, Yarn, Jest, Lerna, etc).

👓 Proposal Updates/Spec Compliancy

AKA the only things most of you care about 😅

Philosophy (Proposals: spec, loose, default behavior)

We’ve created a new repo: babel/proposals to track our progress on the various TC39 Proposals and meetings.

I also added a section about how we accept new proposals. Our basic thinking is that we will start accepting PRs for anything a TC39 champion is going to present (Stage 0). And we will update them (with your help!) when the spec changes.

Naturally, we will take the opportunity to be as spec compliant as possible (within reasonable speed, etc) as the default behavior. This means if you need a faster/smaller build, you should use the loose option which will purposely disregard certain spec changes like runtime checks and other edge cases. The reason why it is opt-in is because we expect you should know what you are doing, while others should be able to seamlessly upgrade babel-preset-env to use the native version of each syntax or stop using Babel entirely and have no issues.

Stage 3: Class Properties (from Stage 2)

babel-plugin-transform-class-properties: the default behavior is now what was previously the “spec” option, which uses Object.defineProperty instead of simple assignment.

This currently has the effect of breaking the legacy decorators plugin (which we made the “transform-decorators” plugin in 7.0) if you try to decorate a class property. You’ll need to use the loose option to be compatible with the version of decorators in the transform until we release the Stage 2 decorators plugin.

Private fields are WIP: #6120

Input

class Bork {
  static a = 'foo';
  x = 'bar';
}

Output (default)

class Bork {
  constructor() {
    Object.defineProperty(this, "x", {
      configurable: true,
      enumerable: true,
      writable: true,
      value: 'bar'
    });
  }
};

Object.defineProperty(Bork, "a", {
  configurable: true,
  enumerable: true,
  writable: true,
  value: 'foo'
});

Output (loose mode)

class Bork {
  constructor() {
    this.x = 'bar';
  }
};
Bork.a = 'foo';

Stage 3: Object Rest Spread (from Stage 2)

babel-plugin-transform-object-rest-spread: And now the plugin handles non-string keys (ex: Number/Symbol)

Input

// Rest Properties
let { x, y, ...z } = { x: 1, y: 2, a: 3, b: 4 };
console.log(x); // 1
console.log(y); // 2
console.log(z); // { a: 3, b: 4 }

// Spread Properties
let n = { x, y, ...z };
console.log(n); // { x: 1, y: 2, a: 3, b: 4 }

Also disallowed

var { ...{ x } } = obj;
var { ...[ y ] } = obj;

Stage 3: Optional Catch Binding (new)

babel-plugin-transform-optional-catch-binding: allow developers to use try/catch without creating an unused binding.

Input

try {
  throw 0;
} catch {
  doSomethingWhichDoesntCareAboutTheValueThrown();
}

Output

try {
  throw 0;
} catch (_unused) {
  doSomethingWhichDoesntCareAboutTheValueThrown();
}

Stage 3: Unicode Property Regex (new)

babel-plugin-transform-unicode-property-regex: compile Unicode property escapes (\p{…} and \P{…}) in Unicode regular expressions to ES5 or ES6 that works in today’s environments.

Input

var regex = /\p{ASCII_Hex_Digit}/u;

Output

var regex = /[0-9A-Fa-f]/;

Stage 3: BigInt (new, unfinished)

babel-plugin-transform-bigint: #6015. This won’t be included in the Stage presets because it would be slow to wrap all operators.

Input

50000n + 60n;

Output

import babelCheckBinaryExpressions from "babel-check-binary-expressions";
babelCheckBinaryExpressions(new BigInt("50000"), new BigInt("60"), "+");

Stage 3: Dynamic Import (from Stage 2)

babel-plugin-syntax-dynamic-import: You only need to parse the syntax since tools like Webpack can handle the transformation in place of Babel. There is also a plugin for Node

Input

const testModule = import('test-module');

Stage 2: `import.meta` (syntax only)

A meta property that is only syntactically valid in modules, meant for meta-information about the currently running module provided by the host environment.

Input

const size = import.meta.scriptElement.dataset.size || 300;

Stage 2: Numeric Seperators (new)

babel-plugin-transform-numeric-separator: make numeric literals more readable by creating a visual separation (a _) between groups of digits.

Input

1_000_000_000
0b1010_0001_1000_0101
0xA0_B0_C0

Output

1000000000
0b1010000110000101
0xA0B0C0

Stage 2: Decorators (from Stage 1), still WIP

babel-plugin-transform-decorators: #6107

Disallowed

// no computed decorator keys
@dec[foo]
class A {}

// no parameter decorators (a separate proposal)
class Foo {
  constructor(@foo x) {}
}

// no decorators on object methods
var o = {
  @baz
  foo() {}
}

// decorator cannot be attached to the export
@foo
export default class {}

Valid

// decorators with a call expression
@foo('bar')
class A {
  // decorators on computed methods
  @autobind
  [method](arg) {}
  // decorators on generator functions
  @deco
  *gen() {}
  // decorators with a member expression
  @a.b.c(e, f)
  m() {}
}

// exported decorator classes
export default @foo class {}

Unsupported (WIP)

// decorated class properties
class A {
  @dec name = 0
}

Stage 2: `function.sent` (new)

babel-plugin-transform-function-sent: compile the function.sent meta property, used inside generator functions

Input

function* generator() {
    console.log("Sent", function.sent);
    console.log("Yield", yield);
}

const iterator = generator();
iterator.next(1); // Logs "Sent 1"
iterator.next(2); // Logs "Yield 2"

Output

let generator = _skipFirstGeneratorNext(function* () {
    const _functionSent = yield;
    console.log("Sent", _functionSent);
    console.log("Yield", yield);
});

Stage 2: export-ns-from

babel-plugin-transform-export-namespace: a shorthand to import/reexport a namespace. Split out from the old transform-export-extensions which combined this proposal with another

Input

export * as ns from "mod";

Output

import * as ns from "mod";
export {ns};

Stage 1: export-default-from

babel-plugin-transform-export-default: a shorthand to import/reexport something. Split out from the old transform-export-extensions which combined this proposal with another

Input

export v from "mod";

Output

import _v from "module";
export { _v as v };

Stage 1: Optional Chaining (new)

babel-plugin-transform-optional-chaining: the operator (?.) allows you to handle properties of deeply nested objects without worrying about undefined intermediate objects.

Input

a?.b = 42;

Output

var _a;
(_a = a) == null ? void 0 : _a.b = 42;

ES2015: `new.target`

babel-plugin-transform-new-target: we never got around to implementing new.target support earlier, so now there is a plugin for it that will be included in the ES2015/env presets.

Example

// with a function
function Foo() {
  console.log(new.target);
}

Foo(); // => undefined
new Foo(); // => Foo

// with classes
class Foo {
  constructor() {
    console.log(new.target);
  }
}

class Bar extends Foo {
}

new Foo(); // => Foo
new Bar(); // => Bar

Input

class Foo {
  constructor() {
    new.target;
  }

  test() {
    new.target;
  }
}

Output

class Foo {
  constructor() {
    this.constructor;
  }

  test() {
    void 0;
  }
}

🚀 New Feature

`.babelrc.js`

babel/babel#4630

*.js configuration files are fairly common in the JavaScript ecosystem. ESLint and Webpack both allow for .eslintrc.js and webpack.config.js configuration files, respectively.

Writing configuration files in JavaScript allows for dynamic configuration, making it possible to write a single configuration file that can adapt to different environments programmatically.

var env = process.env.BABEL_ENV || process.env.NODE_ENV;
var plugins = [];
if (env === 'production') {
  plugins.push.apply(plugins, ["a-super-cool-babel-plugin"]);
}
module.exports = { plugins };

var env = process.env.BABEL_ENV || process.env.NODE_ENV;
module.exports = {
  plugins: [
    env === 'production' && "another-super-cool-babel-plugin"
  ].filter(Boolean)
};

This was previously done through the env configuration option, which is now deprecated. See below for more details.

TypeScript

You can now use babel-preset-typescript to allow Babel to strip types similar to how babel-preset-flow works!

{
  "presets": ["typescript"]
}

We’re working on a guide for how to setup TypeScript and Babel with the TypeScript team, which should be finished before the official 7.0 release. TL;DR is that you setup TS with --no-emit or use it in the editor/watch mode so that you can use preset-env and other Babel plugins.

“Pure” Annotation in specific transforms for minifiers

After #6209, ES6 classes that are transpiled will have a /*#__PURE__*/ comment that minfiers like Uglify and babel-minify can use for dead code elimination. These annotations may expand to our helper functions as well.

Input

class C {
  m(x) {
    return 'a';
  }
}

Output

var C = /*#__PURE__*/ function () {
  function C() {
    _classCallCheck(this, C)
  }
  C.prototype.m = function m(x) {
    return 'a';
  };
  return C;
}();

😎 Other Breaking Changes

Removed `babel-preset-flow` from `babel-preset-react`

This was important because we got a lot of complaints from users that weren’t using any types/flow that they ended up writing invalid JS but there was no syntax error because they used the react preset.

Also we have the TypeScript preset now, so it didn’t make sense to include flow in the react preset itself anymore.

Integrations

Packages like grunt-babel, gulp-babel, rollup-plugin-babel, etc all used to have babel-core as a dependency.

After v7, we plan to move babel-core to be a peerDependency like babel-loader has. This lets all these packages not have to bump major versions when the babel-core API hasn’t changed. Thus they are already published as 7.0.0 since we don’t expect any further changes to those packages.

💀 Possible Deprecations

Deprecate the “env” option in `.babelrc`

babel/babel#5276

The “env” configuration option (not to be confused with babel-preset-env) has been a source of confusion for our users as seen by the numerous issues reported.

The current behavior is to merge the config values into the top level values which isn’t always intuitive such that developers end up putting nothing in the top level and just duplicating all the presets/plugins under separate envs.

To eliminate the confusion (and help our power users), we’re considering dropping the env config option all together and recommending users use the proposed JS config format (see below).

Deprecate ES20xx presets

We already deprecated preset-latest a while ago, and ES2016/ES2017 earlier It’s annoying making a yearly preset (extra package/dependency, issues with npm package squatting unless we do scoped packages)

Developers shouldn’t even need to make the decision of what yearly preset to use? If we drop/deprecate these presets then everyone can use babel-preset-env instead which will already update as the spec changes.

🤔 Questions

Deprecate/Rename/Remove Stage X presets

We’ll probably keep these and just make major version bumps.

Many in the community (and TC39) have expressed concerns over the Stage X presets. I believe I just added them to have an easy migration path from Babel 5 to Babel 6 (used to be a “stage” option).

While we want to have an easy to use tool, it turns out that many companies/developers use these “not yet JavaScript” presets all the time, and in production. “Stage 0” doesn’t really set the same tone as babel-preset-dont-use-this-stage-0.

Ariya just made an awesome poll that explains what I’m talking about

Developers don’t actually know what features are in what version of JavaScript (and they shouldn’t have to know). However it is a problem when we all start thinking that “features” that are actually still proposals are in the spec already.

Many open source projects (including Babel still 😝), tutorials, conference talks, etc all use stage-0. React promotes the use of JSX, class properties (now Stage 3), object rest/spread (now Stage 3) and we all believe that it’s just JavaScript because Babel compiled it for them. So maybe removing this abstraction would help people understand more about what is going on and the tradeoffs one is making when choosing to use Stage X plugins.

It also seems much easier to maintain your own preset than to have to update the Stage preset.

I often see people go “I want object rest, and that’s stage 2, so I enabled stage 2”. They now have a load of other experimental features enabled they might not know about and probably don’t need. Also, as stages change over time then people who aren’t using shrinkwrap or yarn will get new features appearing, possibly without their knowledge. If a feature is canned they might even get one vanishing. @glenjamin

Using npm Scoped Packages

Thoughts on @babeljs using npm scoped packages for 7.0?
— Henry Zhu (@left_pad) January 18, 2017

Seems like most who understood what scoped packages are were in favor?

Pros

Don’t have to worry about getting a certain package name (the reason why this was brought up in the first place).

Many package names have been taken (preset-es2016, preset-es2017, 2020, 2040, etc). Can always ask to transfer but not always easy to do and can lead to users believing certain packages are official due to the naming.

Cons

We need to migrate to new syntax
Still unsupported on certain non-npm tools (lock-in)
No download counts unless we alias back to old names

Sounds like we may want to defer, and in the very least it’s not a breaking change given it’s a name change.

`external-helpers`, `transform-runtime`, `babel-polyfill`

“regeneratorRuntime is not defined” - reported all the time.

Basically we need a better solution around how to deal with built-ins/polyfills.

Developers don’t know what regenerator-runtime is, they just want to use generators/async functions.
Many developers are confused as to why a runtime is needed at all or why Babel doesn’t compile Promise, Object.assign, or some other built-in.
Developers are confused with the difference between transform-runtime the Babel plugin and the runtime itself, babel-runtime.
Complaints about generated code size since babel-polyfill includes all polyfills (although now we have useBuiltIns) and no one knowing about external-helpers

Can we combine/replace these packages and have an easier, default experience?

What’s next?

We want the community to upgrade and provide their feedback/reports. There will probably be a lot of initial activity which can be overwhelming so please be patient with us. We’d appreciate the help in helping triage, write docs/upgrade guides/tips, and codemods to help others upgrade more seamlessly. Because Babel touches a lot of the JavaScript ecosystem, it may not be as simple as simply updating one package because it could depend on other community Babel plugins on npm. We’re not going to just wait around for a month and hope people upgrade, there’s a lot of work to be done to make this happen without half the community still staying on 6.x next year. I’d not like to leave projects (and people) behind. So let us know what we can do to help, and I’d ask that you’d do the same for us and the rest of the community.

Project Sustainibility

Shoutout to my team at Behance for allowing me to work on Babel part-time at work; we’re still basically the only company working to sustain Babel in any capacity on work time. I’m really glad to be able to support the project at work instead of only after work/weekends, and hope this can be the case for more maintainers in the future. (I hope we’ve been a good example of how companies can support the open source projects they use and not necessarily “own”).

We don’t have enough in our Open Collective still to pay someone full time: I believe the highest donation we’ve gotten is $750 from Webflow, and highest monthly donation is $100 from various individuals/companies, so either we some work there or we work on getting more companies involved like AMP/Google have done (@jridgewell who recently joined our team is able to spend work time as well, and it’s made a big difference).

Ask if your company can sponsor with our Open Collective, let us know what’s missing, how you can get involved. You don’t even have to have a specific reason to get involved. If you simply care about sustaining a project for the forseable future, just get your team plugged in and get involved.

Future

After 7.0: there’s a lot of potential avenues for us to explore (that we’ve all brought up years ago): separating traversal from plugins (async visitors?), immutable AST, syntax extensions? On the infra side: integrating with test262 and smoke tests, better github workflow to go from proposal to transform, codemod infrastructure for automatic upgrades, etc.

Follow our meeting notes/discussions on babel/notes and get involved!

Thanks!

I’m hopeful that we can do the official release soon, but I’d like to mention that open source is sustained by consistent, day-to-day maintenance and not just a hyped-up release cycle where we just leave everyone else in the dust and move on so it may take a little longer as we wait to fixup bugs and upgrade the ecoystem.

Zero-config code transformation with babel-macros

Mon, 11 Sep 2017 11:00:00 +0000

Babel started out as a transpiler to let you write the latest version of the ECMAScript specification but ship to environments that don’t implement those features yet. But it has become much more than that. “Compilers are the New Frameworks” says Tom Dale and I could not agree more. We’re seeing more and more compile-time optimizations for libraries and frameworks. I’m not talking about syntax extensions to the language, but simple code transformations that enable patterns that would be difficult to accomplish otherwise.

One of my favorite things about compiler plugins is that you can use them to optimize the user experience and developer experience at the same time. (Read more about “How writing custom Babel & ESLint plugins can increase productivity & improve user experience”).

I have a few problems with Babel plugins though:

They can lead to confusion because when looking at code in a project, you might not know that there’s a plugin transforming that code.
They have to be globally configured or configured out-of-band (in a .babelrc or webpack config).
They can conflict in very confusing ways due to the fact that all babel plugins run simultaneously (on a single walk of Babel’s AST).

These problems could be solved if we could import Babel plugins and apply them directly to our code. This would mean the transformation is more explicit, we wouldn’t need to add them to configuration, and ordering can happen in the order the plugins are imported. Wouldn’t that be cool!?!?

Introducing `babel-macros` 🎣

Guess what! A tool like this exists! babel-macros is a new Babel plugin that allows you to do exactly what we’re talking about. It’s a “new” approach to code transformation. It enables you to have zero-config, importable code transformations. The idea came from Sunil Pai and caught my attention in this create-react-app issue.

So what does it look like? Whelp! There are already a few babel-macros packages out there you can try today!

Here’s a real-world example of using preval.macro to inline an SVG in a universal application built with Next.js:

import preval from 'preval.macro'
import glamorous from 'glamorous'

const base64SearchSVG = preval`
  const fs = require('fs')
  const path = require('path')
  const svgString = fs.readFileSync(path.join(__dirname, 'svgs/search.svg'), 'utf8')
  const base64String = new Buffer(svgString).toString('base64')
  module.exports = base64String
`

const SearchBox = glamorous.input('algolia_searchbox', props => ({
  backgroundImage: `url("data:image/svg+xml;base64,${base64SearchSVG}")`,
  // ...
}))

What’s cool about this? Well, the alternative would look exactly like the example above except:

It’s less explicit because there would be no import preval from 'preval.macro' in the source code.
Have to add babel-plugin-preval to your babel configuration.
Need to update your ESLint config to allow for the preval variable as a global.
If you misconfigured babel-plugin-preval you’d get a cryptic error like: Uncaught ReferenceError: preval is not defined.

By using preval.macro with babel-macros, we don’t have any of those problems because:

The import is there and used explicitly.
babel-macros needs to be added to your config, but only once, then you can use all the macros you’d like (even local macros!)
No need to update ESLint config because it’s explicit.
If you misconfigure babel-macros then you’ll get a much more friendly error message that indicates what the actual problem is pointing you to documentation.

So what is it really? The TL;DR is that babel-macros is a simpler way to write and use Babel transforms.

There are already several published babel-macros you can use, including preval.macro, codegen.macro, idx.macro, emotion/macro, tagged-translations/macro, babel-plugin-console/scope.macro, and glamor 🔜.

Conclusion

I think we’ve only begun to scratch the surface of what babel-macros can do. I’m hoping that we can land it in create-react-app so folks using create-react-app can have even more power with zero configuration. I’m really excited to see more Babel plugins expose a macro in addition to the existing plugin functionality they already have. I can’t wait to see folks create macros that are specific to their project needs.

Creating a macros is even easier than a regular Babel plugin, but it does require a bit of knowledge around ASTs and Babel. If this is new to you, there are a, few, resources for you 😀

Good luck to you all! 👋

P.S. I should mention that language macros are not a new concept at all. Being able to teach a language new tricks has been around for a very long time. In fact, there’s already such a tool for JavaScript and even one implemented as a Babel plugin already. babel-macros takes a slightly different approach however. While macros have often been associated with defining new syntax for a language, that’s not the goal of babel-macros at all. In the case of babel-macros it’s more about code transformations.

Contributing to Babel: Three Lessons to Remember

Wed, 16 Aug 2017 14:00:00 +0000

Getting to work your way around a new code base always poses its challenges, and Babel was no exception.

I’ve been working with Babel as part of the Google Summer of Code 2017 program, working to update Babel transforms and the Babylon parser to accommodate changes to specifications and implementing new features.

Here’s a few things I’ve learnt from my adventures so far.

1. Yes, communication is important

To start off with getting to know the codebase better, I combed through the open issues list on Babel and found a relatively easy one (issue #5728) to deal with.

Just to make sure I knew what I was doing, I fired a quick question on the thread:

After getting clarification, I set off to change the plugin to not throw “runtime” errors during transpilation, but only when the code is actually being run. One incriminating piece of code stuck out:

for (const violation of (binding.constantViolations: Array)) {
  throw violation.buildCodeFrameError(messages.get("readOnly", name));
}

Now what needed to be done here was to actually insert a throw statement into the generated code, which didn’t prove to be too difficult. However, there were still a few cases where runtime errors were being thrown elsewhere from code that wasn’t directly related to this file.

Wanting to go and explore other parts of the Babel code base, I put that down for me to get on with later.

Not too long after, I received a, well, interesting update on the issue… Wait what?

I never actually said I was working on fixing the issue, but assumed that posting would have implied I was going to work on it.

Oops.

2. Where snapshot testing falls short

After setting off for another hunt, I stumbled across issue #5656:

Arguments deoptimized when shadowed in nested function

This is a feature request (I think). Arguments are not optimized if an inner function shadows the name with a parameter (or rest parameters in my case).

Input code
const log = (...args) => console.log(...args);

function test_opt(...args) {
  log(...args);
}

function test_deopt(...args) {
  const fn = (...args) => log(...args);
  fn(...args);
}
…

Expected vs. Current Behavior

I’d expect the code to be optimizable to use .apply( thisArg, arguments ) throughout. However, in test_deopt the outer …args gets copied just to be passed into the inner fn. I can verify that the problem disappears if I rename either the …args of test_deopt or of the fn arrow function.

What’s going on here?

Now what was happening was that this code would generate the following:

var log = function log() {
  var _console;

  return (_console = console).log.apply(_console, arguments);
};

function test_opt() {
  log.apply(undefined, arguments);
}

function test_deopt() {
  for (var _len = arguments.length, args = Array(_len), _key = 0; _key < _len; _key++) { // unnecessary loop
    args[_key] = arguments[_key];
  }

  var fn = function fn() {
    return log.apply(undefined, arguments);
  };
  fn.apply(undefined, args);
}

See that for section there? Usually this is needed as the arguments object isn’t a real array — for example, if you tried to run arguments.slice(), it would fail miserably. However, in this case it’s only being passed to Function.prototype.apply. Surprisingly enough, Babel already bothers to optimize this specific case, like in the test_opt example above.

Trying to fix it

So what did I do? Adding the problem file as a new test case, I tried to see if I could get the output to reflect what I wanted.

“Why’s the test failing? Surely if I change it a little it will solve itself.”

Despite spamming make test-only and modifying the transforms of referenced identifiers within the code, any change just resulted in a different bunch of tests failing instead.

The Chromium debugger is “fun”

Miserable, annoyed and confused, I bothered to fire up the Node.js inspector to step through what was going on.

After returning to my computer from a drink break, I’m gladly greeted to my hard disk light thrashing around and a practically hung computer.

Holding my computer together with judicious applications of Alt + SysRq + F, I managed to work through the flow of things¹ and figure out how exactly the code worked.

Even through all that, I still couldn’t see any reason why it was deciding to remove this “necessary” (so I thought) code that was being removed with my original fix.

The actual problem?

See the error shown above? That entire code in green wasn’t meant to be there, even though it was “expected”.

Basically: the test was broken. Great. :/

The actual fix involved creating a referencesRest function to make sure that the spread operator was actually being applied to the original parameter, rather than a variable in another scope masking the variable.

¹: Turns out that adding a large folder to the DevTools workspace would leak memory until causing an OOM (bug I filed for this).

So why do we use snapshot testing then?!

Well first off, it’s far easier to create tests when all you need to do is ask Babel to run your test case to generate your expected file. This presents to us a low time cost option while protecting against a significant proportion of potential errors.

Also, especially with the type of program Babel is, it would be far harder to test for in other ways. For example, we could check for specific nodes of the AST, but this takes far longer to write and is also prone to non-obvious breakage when your code attempts to change the way the transform is done.

So, all in all, a few lessons here:

Make sure your tests are right in the first place—don’t be complacent!
Yes, the debugger is actually useful in seeing what goes on.
Sometimes things take time to work out—if you’re getting nowhere, take a break or work on something else.

3. Team meetings!

I know this kinda stretches the notion of an “issue”, but anyway :)

When you’re working on a project with a bunch of other people, it’s always useful to catch up with one another and discuss areas which we need to work on.

So how exactly do we go about doing that?!

Ugh, meetings.

When you have a bunch of people spread across the world, finding ways to communicate is never easy, but regardless we would have to make do with our attempts at this feat.

Time zones

When you’re dealing with a open source project spanning all across the globe, picking an appropriate hour quickly turns a rather involved exercise in bikeshedding.

Even with the vast spread between each of us, it seemed like we could just about manage to finally get something together.

Alas, this was not to last. Eventually, we ended up having to switch between two times every other week to accommodate other users (13:00 and 16:00 UTC), which meant that I was only able to attend once a fortnight.

Despite this, we’ve managed to make significant progress with coordinating fixes to various parts that make up key changes to Babel, including support for TypeScript, changes to the order in which transform plugins run, as well as keeping up to date with changes from TC39.

Where to next?

We’re continuing to polish up Babel 7 for general consumption, with a number of new features coming along with that.

I’m working with a bunch of others to get support for updated Class Fields specification proposal included into Babel so that people can test it out and provide feedback.

Also, while I’m at it, I’d like to thank all of the Babel mentors and contributors for helping me out with peer reviews and providing guidance with proposals, all the way from first contact to today.

Looking to find out more about Babel? Hit up our contributing page and join the Slack community!

More about Karl

Karl Cheng is a GSoC 2017 student hailing from Sydney, Australia. Find out more about him on GitHub (Qantas94Heavy) and Twitter (@Qantas94Heavy)!

Please check out our first post on Summer of Code for more info!

Personal Experiences at Babel #1 — A PR with Unusually High Number of Reviews

Fri, 11 Aug 2017 12:00:00 +0000

We landed the parser support for the stage-2 decorators spec last week at Babylon — the parser for Babel. If you don’t know what a decorator is, the gist of it is that a decorator gives some concise syntax to affect the definition of a class or a class method which you decorate.

@frozen class Foo {
  @configurable(false)
  @enumerable(true)
  method() {}

  @throttle(500)
  expensiveMethod() {}
}

One of the more remarkable things about this PR was the number of reviews it received

Perhaps this could be because decorators really are one of the much hyped about features in JavaScript. Angular even considered making their own JS flavor called AtScript before they decided to go with TypeScript since they love decorators (or as they liked to call it “annotations”) so much.

Well, there is more to the story. As I was recently discussing with a mentor, reviewing PRs is a tough job. Reviewing PRs is comparably as hard as solving the bug in the first place was. Apart from the technical aspect of reviewing — which is ensuring that the bug is being fixed optimally (by perhaps even getting an idea of how they would solve the issue and seeing how the submitted patch compares to their idea) — there’s another big hindrance. A reviewer has to be aware of the whole issue, the discussion surrounding it, and have familiarity with the part of the codebase that the PR makes changes to.¹

When I initially joined Babel, and was not-so-familiar with the codebase, every issue I encountered was almost instantly answered after I posted it in Babel’s chatroom, which left me with the (wrong) impression that perhaps the maintainers are some god-like figures who know it all and that everyone’s expected to adhere to the same fictitious standards.

Even after becoming familiar with the codebase, I was submitting PRs without proper documentation under the assumption that it took me a while to solve the issue and see all things, but if the reviewers see the code they’d instantly be able to evaluate it just like they were answering my questions.

Eh! Very wrong. Let me just bust this myth (assuming I’m not the only one who has felt it). Even they (maintainers) won’t have all the answers at times, and sometimes you’ll have to search for yourself — and that’s how it should be.²

In open source, there are a lot of people who want to contribute, but are unable to because they don’t know how to code / they don’t know how to present PRs / they don’t know what the project wants / they don’t know what the maintainers want / a ton of other things. A lot of times you’ll find help along the way, but a lot of that is controlled by factors beyond your control.³

One of the joys of getting your PR merged is not just the programming but somehow making the project move forward in the way it is expected to be moved forward. And doing that by somehow identifying what the project needs and being able to deliver that.

In order to merge this PR I had to find people and talk to them — people who use decorators, people who are interested in seeing an implementation of decorators, people who want to contribute to babel for decorators. After getting consensus on how to move forward⁴, I had to go through the spec and all the existing discussions surrounding it so that my understanding of the spec could be up to speed with other people.

And finally — the most important part which I think got this PR the number of reviews that we saw — making it easy for people who’ll be reviewing my PR by explaining everything they would need to get up to speed with the whole situation. By chance, at the time the PR I made was able to satisfy some of the criteria I mentioned earlier:

Making sure reviewers are aware of the whole issue (by mentioning in detail the decisions I’ve taken so they don’t necessarily have to look at the code to figure it out)
The discussion surrounding it (by mentioning alternate viewpoints on some of the decisions so as to make it easier to compare them with the decisions made)
Explaining clearly my strategy to solve the problem (to assist the technical aspect of reviewing — so that the reviewers can know what I’ve done and then see the code rather than the other way around)

And that’s what did it! (or so I think). So there’s the mystery unraveled — A PR with unusually high number of reviews¹.

PS: I wanted to share my personal experience with this blog post, not write a guide to be followed or a technical blog post. Therefore, some statements which I make may not hold true in general or may be debatable, so they should just be read in the context of the experience I narrate.

Also note that if you’re looking for decorators support in Babel, we still have a long way to go. This is just the parser and work on the transform (which converts your code to functionally equivalent ES5) is yet to be done. But now that we’ve made the decisions that needed to be made, things will move more smoothly from here onwards.

Footnotes

We have a shortage of manpower when it comes to reviewing PRs. It was also recently discussed in one of our weekly meetings (link to the meeting notes). Perhaps you could help us with this. Drop by our slack chatroom and offer your help!
I feel that the myth stems from the fact that when you’re new to the project the mentors definitely do know more about the project than you
(to illustrate) Some random factors which might affect the chances of you getting help:
- If someone was online who worked on the same thing when you post a question on the chatroom
- Someone who knows your doubt will take a lot of time to deal with and they want to give you personal attention and not just throw information at you
- Someone who’s able to gauge where you’re coming from, and so on.
We’d been stuck for a while since a lot of people use a nonstandard implementation for decorators which came at around the time the spec was in stage-0. The changes in the spec are not backwards-compatible so we were unsure on how we should introduce support for the new spec without causing much disruption for people who use Babel. We finally decided that we’ll be introducing this PR as an opt-in to allow people to migrate at their own pace.

Outro

Peeyush Kushwaha is a GSoC 2017 student. Give him a follow on Twitter: @PeeyFTW!

This was originally posted here on medium. Please check out our first post on Summer of Code for more info!

Babel and Summer of Code 2017

Wed, 09 Aug 2017 12:00:00 +0000

For the first time, Babel is participating in Summer of Code! Although we forgot to make an announcement post earlier, here’s our progress update 😊

What is it?

Google Summer of Code

Babel’s Profile for GSoC

GSoC is an international annual program which pairs open source projects and university students! We work with the students on a project and Google pays them a stipend.

Peeyush Kushwaha (India)

Github: @peey, Twitter: @peeyFTW

Karl Cheng (Australia)

Github: @Qantas94Heavy, Twitter: @qantas94heavy

We’re happy to be working with both Peeyush and Karl!

Peeyush has already made a bunch of PRs with improving documentation and bug fixes. In addition, he’s been focusing on the much desired decorators transform. We’ll be updating this issue with more progress.

Karl has similarly made many contributions already, and is now focusing on the private properties transform (now part of the combined class properties proposal). We’ll be updating this issue with more progress.

To track their work on these transforms and the progress of other specs/proposals, be sure to check out the Babel TC39 Proposal Status Tracker.

It’s been really amazing working with them the past 2 months! We’ve really enjoyed teaching, working, and learning with them on the project. Partnering with TC39 in making these Babel plugins a reality has also been helpful for everyone.

Rails Girls Summer of Code

Babel’s RGSoC Page

RGSoC is a similar program to GSOC: annual, global, pays a stipend, brings projects and newcomers together, with a focus on bringing diversity into Open Source.

Kara de la Marck (London)

Github: @MarckK, Twitter: @KaraMarck

Emma Deacon (London)

Github: @EmmaDeacon, Twitter: @EmmaMDeacon

Where RGSoC differs from GSoC is that it matches developers with team coaches in addition to the open source project’s mentors. Pivotal London is working with Kara and Emma as their daily coworkers/supporters. We are lucky to have seven awesome coaches from their organization to help them, while on our side we can leave feedback on issues/PRs in GitHub and in our Slack.

We’re incredibly lucky to work with both Kara and Emma!

They’re currently working on some codemods! Ideally we would have codemods to convert ES2015 to ES2016+ (Lebab) and if necessary, codemods to remove dropped TC39 proposals. We’d also want to have codemods for our upcoming Babel 7 release for a easy/automated upgrade!

In the meantime, they’ve already done all the necessary work to implement the new optional catch binding proposal as a plugin! It was really cool to see that we had already released the Babel plugin before the TC39 meeting a few weeks ago! You can follow this issue for more information.

Why?

Participating in these programs means more developer exposure to participating in open source!
Helps us as a project onboard and mentor new contributors in a more formal, structured way. It helps us identify any issues with our code setup, and more importantly with our process (multiple timezones, different backgrounds) and culture.
Helps bring in different people into the project that otherwise may not have contributed to Babel or open source. The hope is that they continue to stick around or be involved in the open source community! We want to do our part to make open source a welcoming and diverse community, focusing on individuals first.
We get four full time people working on our project for a whole summer! This is a great opportunity for each of them to work on high impact problems, and for us to be in a support role to help them succeed.
Hopefully it inspires some to get involved as a result of the program, and for others to step up as mentors/maintainers (ideally from the hundreds of top companies that use this project everyday) to bring people in.
Ultimately, this is just about building a community and making a great experience for our students/interns.

It takes a lot of work to get involved in any community, and it’s up to the people aleady involved to make this as easy as possible to join in. It requires one to spend the time to meet people where they are at (in many ways), not just write code but to invest in others. A community is about the people, and open source is about the community.

Participating in Summer of Code gives us a great opportunity to make this happen, and we’re continuously working on improving.

Look at all the amazing work they’ve already done! We’re really excited for what’s to come and will do another post on our results and what we’ve learned.

Look out for next year’s RGSoC and GSoC if you want to participate (for your own project, as a participant, or to help us out) cough Sean.

Thanks

To my team at Behance/Adobe for allowing me to spend time at work maintaining Babel and participating in Summer of Code!

Thanks to all the other helpers/maintainers (Brian, Logan, Diogo, Sven, Justin, Boopathi), on Slack and GitHub issues! It can be a lot of work managing all the parts of an open source project, so we are glad to have the extra help!

Huge shoutout to many TC39 members like @littledan, @bakkoting, @ljharb for helping review PRs, better inform/work on babel/proposals, and discuss implementation/spec details in our Slack rooms! I know it’s a lot of work 🙂

And thanks to Brian again for help with editing!

Upgrade to Babel 7 (WIP)

Wed, 01 Mar 2017 11:00:00 +0000

Refer users to this document when upgrading to Babel 7 (currently alpha).

Because not every breaking change will affect every project, we’ve sorted the sections by the likelihood of a change breaking tests when upgrading.

All of Babel

Support for Node.js 0.10 and 0.12 has been dropped #5025, #5041, #5186

We highly encourage you to use a newer version of Node.js (LTS v4, LTS v6) since the previous versions are not maintained. See nodejs/LTS for more information.

This just means Babel itself won’t run on older versions of Node. It can still output code that runs on old Node.

Option parsing

Babel’s config options are stricter than in Babel 6. Where a comma-separated list for presets, e.g. presets: 'es2015,es2016' technically worked before, it will now fail and need to be changed to an array #5463. This does not apply to the CLI, where --presets es2015,es2016 will certainly still work.

Resolving string-based config values

In Babel 6, values passed to Babel directly (not from a config file), were resolved relative to the files being compiled, which led to lots of confusion. In Babel 7, values are resolved consistently either relative to the config file that loaded them, or relative to the working directory.

For presets and plugins values, this change means that the CLI will behave nicely in cases such as

babel --presets es2015 ../file.js

Assuming your node_modules folder is in ., in Babel 6 this would fail because the preset could not be found.

This change also affects only and ignore which will be expanded on next.

Path-based `only` and `ignore` patterns

In Babel 6, only and ignore were treated as a general matching string, rather than a filepath glob. This meant that for instance *.foo.js would match ./**/*.foo.js, which was confusing and surprising to most users.

In Babel 7, these are now treated as path-based glob patterns which can either be relative or absolute paths. This means that if you were using these patterns, you’ll probably need to at least add a **/ prefix to them now to ensure that your patterns match deeply into directories.

only and ignore patterns do still also work for directories, so you could also use only: './tests' to only compile files in your tests directory, with no need to use **/*.js to match all nested files.

Babel’s CLI commands

The --copy-files argument for the babel command, which tells Babel to copy all files in a directory that Babel doesn’t know how to handle, will also now copy files that failed an only/ignore check, where before it would silently skip all ignored files.

babel-preset-stage-3

Remove Stage 4 plugins from Stage 3 #5126

These plugins were moved into their yearly presets after moving to Stage 4:

babel-plugin-syntax-trailing-function-commas (babel-preset-es2017) babel-plugin-transform-async-to-generator (babel-preset-es2017) babel-plugin-transform-exponentiation-operator (babel-preset-es2016)

Instead of any yearly preset, we suggest that you use the newly created babel-preset-env which uses the correct plugins based on your environment.

Before:

{
  "presets": ["es2015", "es2016", "es2017"]
}

After:

{
  "presets": ["env"]
}

{
  "presets": [
    ["env", {
      "targets": {
        "browsers": ["last 2 versions", "safari >= 7"]
      }
    }]
  ]
}

See /docs/plugins/preset-env/ for more information.

Spec Compliancy

A trailing comma cannot come after a RestElement in objects #290

This is when you are using babel-plugin-transform-object-rest-spread.

Before:

var { ...y, } = { a: 1};

This will now throw a syntax error.

After:

var { ...y } = { a: 1};

babel-core

babel-core/register.js has been removed #5132

The deprecated usage of babel-core/register has been removed in Babel 7; instead use the standalone package babel-register.

Install babel-register as a new dependency:

npm install --save-dev babel-register

Upgrading with Mocha:

mocha --compilers js:babel-core/register

to:

mocha --compilers js:babel-register

See babel-register documentation for more information.

babel-plugin-transform-class-constructor-call

babel-plugin-transform-class-constructor-call has been removed #5119

TC39 decided to drop this proposal.

Before:

class Point {

  constructor(x, y) {
    this.x = x;
    this.y = y;
  }

  call constructor(x, y) {
    return new Point(x, y);
  }

}

let p1 = new Point(1, 2);
let p2 = Point(3, 4);

You can move your logic into the constructor or into a static method.

Example with a static method:

class Point {

  constructor(x, y) {
    this.x = x;
    this.y = y;
  }

  static secondConstructor(x, y) {
    return new Point(x, y);
  }

}

let p1 = new Point(1, 2);
let p2 = Point.secondConstructor(3, 4);

See /docs/plugins/transform-class-constructor-call/ for more information.

babel-plugin-transform-es2015-template-literals

Template Literals Revision updated #5523

See the proposal for Template Literals Revision.

It cause Babel 6 to throw Bad character escape sequence (5:6).

tag`\unicode and \u{55}`;

This has been fixed in Babel 7 and generates something like the following:

function _taggedTemplateLiteral(strings, raw) { return Object.freeze(Object.defineProperties(strings, { raw: { value: Object.freeze(raw) } })); }
var _templateObject = _taggedTemplateLiteral([], ["\\unicode and \\u{55}"]);
tag(_templateObject);

babel

Dropping the babel package #5293

This package currently gives you an error message to install babel-cli instead in v6. We will just not publish a v7 version. It also doesn’t make sense if we switch to scoped package babel -> @babel/babel?

babel-generator

Dropping the quotes option #5154]

If you want formatting for compiled output you can use recast/prettier/escodegen/fork babel-generator.

This option was only available through babel-generator explicitly until v6.18.0 when we exposed parserOpts and generatorOpts. Because there was a bug in that release no one should’ve used this option in Babel itself.

Dropping the flowUsesCommas option #5123

Currently there are 2 supported syntaxes (, and ;) in Flow Object Types.

This change just makes babel-generator output , instead of ;.

babel-core

Remove babel-core/src/api/browser.js #5124

babel-browser was already removed in 6.0. If you need to use Babel in the browser or a non-Node environment, use babel-standalone.

Upgrade to Babel 7 for Tool Authors (WIP)

Wed, 01 Mar 2017 11:00:00 +0000

Refer users to this document for those that create tools that depend on Babel (such as Babel plugins).

Also check out the User Upgrade Guide for other relevant changes.

All Babel packages

NodeJS support

Support for Node.js 0.10 and 0.12 has been dropped as both of this versions are out of maintenance.

Export changes

Dropped use of add-module-exports plugin on Babel packages. This had to be used earlier to prevent a breaking change with our exports. If you import a Babel package in a library you may need to use .default when using require rather than import.

`babel-core`

The publicly exposed but undocumented Pipeline class has been removed. Best to use the transformation methods exposed from babel-core directly babel/babel#5376.

The babel.util.* helper methods have been removed, and util.EXTENSIONS has been moved to babel.DEFAULT_EXTENSIONS babel/babel#5487.

Calls to babel.transform or any other transform function may return null if the file matched an ignore pattern or failed to match an only pattern babel/babel#5487.

The opts.basename option exposed on state.file.opts has been removed. If you need it, best to build it from opts.filename yourself babel/babel#5467.

Babylon

Removed the * plugin option #301

This was first added in v6.14.1 (Nov 17, 2016) so it’s unlikely anyone was using this.

This catch-all option was removed; instead you should specifically decide which plugins you want to activate.

We thought it would be a good idea for tools so they wouldn’t have to constantly update their config but it also means we can’t easily make a breaking change.

Before:

babylon.parse(code, {
  plugins: [ "*" ]
})

You can get the old behavior using:

babylon.parse(code, {
  plugins: [
    "asyncGenerators",
    "classProperties",
    "decorators",
    "doExpressions",
    "dynamicImport",
    "exportExtensions",
    "flow",
    "functionBind",
    "functionSent",
    "jsx",
    "objectRestSpread",
  ]
})

See Babylon’s plugin options.

Removed classConstructorCall plugin #291

`babel-traverse`

getFunctionParent will no longer return Program, please use getProgramParent instead #5923.

It doesn’t make sense that a function named getFunctionParent also returns the Program, so that was removed.

To get the equivalent behavior, you’ll need to make a change like

- path.scope.getFunctionParent()
+ path.scope.getFunctionParent() || path.scope.getProgramParent()

Path replacement/removal APIs now return an array of new paths

For instance, using Path#insertBefore, or Path#replaceWith will now always return an array of the newly inserted/replaced paths.

const node = t.nullLiteral();
const [replaced] = path.replaceWith(node);
replace.node === node; // => true

This is especially useful when inserting serveral nodes into some higher-up scope, since you can immediately call the Path APIs on the node’s new Path.

const parent = path.findParent(() => /* some selection criteria */);
const helperPaths = path.unshiftContainer("body", helpers);
// helperPaths can now be referenced, manipulated, etc.

AST changes

Tokens removed

In previous versions tokens were always attached to the AST on the top-level. In the latests version of babylon we removed this behavior and made it disabled by default to improve the performance of the parser. All usages in babel itself have been remove and babel-generator is not using the tokens anymore for pretty printing.

If your babel-plugin uses tokens at the moment, evaluate if it is still necessary and try to remove the usage if possible. If your plugin really depends on getting tokens you can reactivate it but please only consider this if there is no other way as this will hurt users performance.

To activate you need to set the tokens option of babylon to true. You can do this directly from your plugin.

export default function() {
  return {
    manipulateOptions(opts, parserOpts) {
      parserOpts.tokens = true;
    },
    ...
  };
}

Renamed

The following nodes have been renamed:

Name 6.x	Name 7.x	Example	PR
ExistentialTypeParam	ExistsTypeAnnotation	`type A = B<*>;`	#322
NumericLiteralTypeAnnotation	NumberLiteralTypeAnnotation	`type T = 0;`	#332

Besides the AST-Nodes also all the functions in babel-type have been renamed.

 import * as t from "babel-types";

 return {
-  ExistentialTypeParam(path) {
-    const parent = path.findParent((path) => path.isExistentialTypeParam());
-    t.isExistentialTypeParam(parent);
+  ExistsTypeAnnotation(path) {
+    const parent = path.findParent((path) => path.isExistsTypeAnnotation());
+    t.isExistsTypeAnnotation(parent);

-    return t.existentialTypeParam();
+    return t.existsTypeAnnotation();
   },
-  NumericLiteralTypeAnnotation(path) {
-    const parent = path.findParent((path) => path.isNumericLiteralTypeAnnotation());
-    t.isNumericLiteralTypeAnnotation(parent);
+  NumberLiteralTypeAnnotation(path) {
+    const parent = path.findParent((path) => path.isNumberLiteralTypeAnnotation());
+    t.isNumberLiteralTypeAnnotation(parent);

-    return t.numericLiteralTypeAnnotation();
+    return t.numberLiteralTypeAnnotation();
   }
 };

Replaced

On the following AST-Nodes the value of the field variance has been changed from a simple string value to be its own AST-Node called Variance. #333

The field is only available when enabling the flow plugin in babylon.

ObjectProperty
ObjectMethod
AssignmentProperty
ClassMethod
ClassProperty
Property

The type of the new Variance node looks like this:

type VarianceNode = {
  type: "Variance",
  kind: "plus"|"minus",
}

 return {
   Property({ node }) {
-    if (node.variance === "plus") {
+    if (node.variance.kind === "plus") {
       ...
-    } else if (node.variance === "minus") {
+    } else if (node.variance.kind === "minus") {
       ...
     }
   }
 };

Location changes

The location info of ObjectTypeIndexer has been changed to not include semicolons. This was done to align with the flow-parser and have the same location information. #228

Example:

var a: { [a: number]: string; };

 {
   "type": "ObjectTypeIndexer",
   "start": 9,
-  "end": 29,
+  "end": 28,
   "loc": {
     "start": {
       "line": 1,
       "column": 9,
     },
     "end": {
       "line": 1,
-      "column": 29
+      "column": 28
     }
   }
 }

Removal

ForAwaitStatement

The AST-Node ForAwaitStatement has been removed and is replace with the field await in the ForOfStatement node #349

 interface ForOfStatement <: ForInStatement {
   type: "ForOfStatement";
+  await: boolean;
 }

 return {
-  ForAwaitStatement(path) {
-    ...
+  ForOfStatement(path) {
+    if (path.node.await) {
+      ...
+    }
   }
 };

RestProperty & SpreadProperty

The two AST-Nodes RestProperty and SpreadProperty have been removed in favor of reusing RestElement and SpreadElement #384

 return {
   SpreadElement(path) {
-    ...
-  },
-  SpreadProperty(path) {
-    ...
+    if (path.parentPath.isObjectExpression()) {
+      ...
+    } else if (path.parentPath.isArrayExpression()) {
+      ...
+    }
   },
   RestElement(path) {
-    ...
-  },
-  RestProperty(path) {
-    ...
+    if (path.parentPath.isObjectPattern()) {
+      ...
+    } else if (path.parentPath.isArrayPattern()) {
+      ...
+    }
   }
 };

See our upgrade PR for Babel and the Babylon AST spec for more information.

6.23.0 Released

Mon, 13 Feb 2017 20:00:00 +0000

In this release: multiple improvements to the react-constant-elements plugin by @STRML, some codegen optimizations, and lots of bug fixes! Thanks to @loganfsmyth for the release + reviews!

Shoutouts to @xtina-starr, @finkef, @chitchu, @yongxu, @jwbay, @hex13 for their first PRs! 🎉

Check out GitHub for the whole changelog.

I’ll be writing up the 7.0 post (our current progress) soon so look out for that! We want to do whatever we can to make it easy for both end-users and plugin/tool authors to upgrade seamlessly: whether it be a beta period for the release, a 7.0 upgrade guide, codemods if necessary, a bot to automatically upgrade your OSS project from 6 to 7, or any other suggestions you can give us!

Since not everyone realises, I wanted to re-iterate again that our team is still a small group of volunteers. There’s no company sponsor or even anyone working on it full time.

We’d love for you to contribute (especially not code!), so please reach out to us! More designers, technical writers/editors, and teachers for our website would be amazing.

And in other news, Babel has been accepted as a Rails Girls Summer of Code project as well as waiting to hear back as a mentor organization for Google Summer of Code!

🚀 New Feature

#5236 `transform-es2015-block-scoping`: Add option `throwIfClosureRequired` to throw on slow code. (@spicyj)

{
  "plugins": [
    ["transform-es2015-block-scoping", {
      "throwIfClosureRequired": true
    }]
  ]
}

In cases such as the following, it is impossible to rewrite let/const without adding an additional function and closure while transforming:

for (let i = 0; i < 5; i++) {
  setTimeout(() => console.log(i), 1);
}

In extremely performance-sensitive code, this can be undesirable. If "throwIfClosureRequired": true is set, Babel throws when transforming these patterns instead of automatically adding an additional function.

#4812 `transform-react-constant-elements`: Support pure expressions (@STRML)

Adds a path.isPure() check to the plugin.

The expression will remain in the hoisted code, even though it could be statically evaluated. UglifyJS/Babili will take care of that in many cases.

const OFFSET = 3;

var Foo = React.createClass({
  render: function () {
    return (
      <div tabIndex={OFFSET + 1} />
    );
  }
});

Out

const OFFSET = 3;

var _ref = <div tabIndex={OFFSET + 1} />;

var Foo = React.createClass({
  render: function () {
    return _ref;
  }
});

Deopt

As noted in facebook/react#3226, it’s not safe to reuse elements with mutable props.

<div style={
  { width: 100 }
} />

#5288 `babel-preset-flow`: Add new preset (@thejameskyle)

babel-preset-flow just includes transform-flow-strip-types.

Before (still valid)

{
  "plugins": ["transform-flow-strip-types"]
}

After

{
  "presets": ["flow"]
}

FYI: the React preset still includes the flow plugin by default (we might change it when TS support is added)

Thanks to @simnalamburt for giving us the package name!

#5230 `babel-traverse`: Add extra sibling methods (@chitchu)

For plugin authors: there’s already a path.getSibling(number), so we’re adding a few helper methods.

path.getPrevSibling(); // path.getSibling(path.parentPath.key - 1)
path.getNextSibling(); // path.getSibling(path.parentPath.key + 1)
path.getAllPrevSiblings(); // returns Array<NodePath> of previous siblings
path.getAllNextSiblings();// returns Array<NodePath> of next siblings

🐛 Bug Fixes

Because alsmot every bug fix can be an opportunity to learn more about JavaScript and how the tool that you use works, I would check out some of the PRs!

#5298 Fix loose `transform-es2015-for-of` with label. (@jridgewell)

b: for (let c of d()) { // previously, the label was completely dropped
  for (let e of f()) {
    continue b;
  }
}

#5153 `transform-react-constant-elements`: Hoisting fixes (@STRML)

Better hoisting inside variable declarations

Input

function render() {
  const bar = "bar", renderFoo = () => <foo bar={bar} baz={baz} />, baz = "baz";

  return renderFoo();
}

Output

function render() {
  const bar = "bar",
        renderFoo = () => _ref2,
        baz = "baz",
        _ref2 = <foo bar={bar} baz={baz} />;

  return renderFoo();
}

Hoisting with Higher Order Components

Input

const HOC = component => component;

const Parent = () => (
  <div className="parent">
    <Child/>
  </div>
);

export default Parent;

let Child = () => (
  <div className="child">
    ChildTextContent
  </div>
);
Child = HOC(Child);

Output

const HOC = component => component;

const Parent = () => _ref;

export default Parent;

var _ref2 = <div className="child">
    ChildTextContent
  </div>;

let Child = () => _ref2;
Child = HOC(Child);

var _ref = <div className="parent">
    <Child />
  </div>;

#5143 `transform-react-constant-elements`: Fix `PathHoister` hoisting JSX member expressions on `this` (@STRML)

<this.component /> was previously hoisted outside its own function (doesn’t make sense because otherwise this would be undefined)

function render() {
  this.component = "div";
  return () => <this.component />;
}

function render() {
  this.component = "div";

  var _ref = <this.component />;

  return () => _ref;
}

#5030 `transform-do-expressions`: Prevent multiple return statements in a loop when replacing expressions. (@existentialism)

let p
let a = do {
  while (p = p.parentPath) {
    if (a) {
      'a'
    } else {
      'b'
    }
  }
};

let p;
let a = function () {
  var _ret;

  while (p = p.parentPath) {
    if (a) {
      _ret = 'a';
    } else {
      _ret = 'b';
    }
  }
  return _ret; // previously had an extra return
}();

#5260 `babel-register`: Fix a TypeError with the cache. (@xtuc)

#5206 `babel-traverse`: Deopt evaluation of undefined with a local binding (@boopathi)

If undefined, NaN, Infinity are redefined, deopt.

#5195 `babel-plugin-transform-runtime`: Don’t compile certain symbol properties. (@taion)

Don’t pull in the individual Symbol.asyncIterator/Symbol.observable polyfills and pull in the full Symbol polyfill instead.

#5258 `babel`: Check if it is installed globally and displays correct cli message. (@xtina-starr)

Now if you install babel the error message will display either -g or not.

#5270 `babel-generator`: Emit parens for await of ternary expressions. (@erikdesjardins)

async function asdf() {
  await (1 ? 2 : 3);
}

#5193 `babel-generator`: Fix missing parens when `FunctionExpression` is a tag in a template string. (@existentialism)

(() => {})``;
(function(){}``);

#5235 `transform-es2015-modules-commonjs`: Limit export node default assignment stack size #4323. (@mattste)

An interesting issue when importing/exporting a lot!

import { foo, foo1, foo2 ... } from "foo"; // assume ... is 100 imports/exports
export { foo, foo1, foo2 ... }

Part of the generated code looks like:

exports.Foo6 = exports.Foo5 = ...

Thus with a file that exports a lot of modules it creates so many nested assignment nodes in the AST the code generator errors with Maximum call stack size exceeded.

The solution is to break up the expression into sets of 100.

Output

exports.foo100 = undefined; // split by 100
exports.foo99 = exports.foo98 = ... exports.foo1 = exports.foo = undefined

#5255 `babel-generator`: Use `trim` instead of `lodash/trimEnd` for codegen performance (@jwbay)

lodash/trimEnd executes a regex against potentially massive strings which can freeze node. (106ms vs. 5ms)

#5050 `babel-traverse`: Rewrite `Hub` as an interface (@yongxu)

This was reverted due to an incompatible change to babel-core

There are a few cases where babel-traverse can’t be used standalone so this removes some code that tied babel-traverse to babel-core’s implementation.

🌏 Committers: 20

Andres Suarez (zertosh)
Ben Alpert (spicyj)
Boopathi Rajaa (boopathi)
Brian Ng (existentialism)
Christina (xtina-starr) First PR!
Erik Desjardins (erikdesjardins)
Fabian Finke (finkef) First PR!
Henry Zhu (hzoo)
Jimmy Jia (taion)
Justin Ridgewell (jridgewell)
Logan Smyth (loganfsmyth)
Matt Stewart (mattste)
Samuel Reed (STRML)
Sergey Rubanov (chicoxyzzy)
Sven SAULEAU (xtuc)
Vicente Jr Yuchitcho (chitchu) First PR!
Yongxu Ren (yongxu) First PR!
jwbay First PR!
james kyle (thejameskyle)
Łukasz Lityński (hex13) First PR!

Check out Github for the whole changelog!

The State of Babel

Wed, 07 Dec 2016 14:30:00 +0000

Previous issues: Babel Roadmap #4130, 6.0 #2168

Please check out the Community section if nothing else.

Also published as part of Mariko Kosaka’s 2016 Web Advent Calendar!

Some History

Sebastian created “6to5” in September of 2014. Interestingly enough, he made it to scratch an itch he had with understanding programming languages and how they work. You might have assumed whoever created the project already knew how compilers worked and understood JavaScript perfectly… but you would be wrong! Check out his post for a great read of his story: ~2015 in Review.

6to5 did exactly that: easily turn ES6 code into ES5 code. When 6to5 became Babel as mentioned in Not Born to Die, it became a platform: a suite of tools designed to create the next generation of JavaScript tooling. No longer did it just compile ES6 to ES5, it allowed developers to build tools on top of it.

Here are some of our milestones:

In 5.0.0, Babel aligned more with the TC39 process by introducing stages, added a .babelrc config option, and created a plugin system for custom transforms.
In 6.0.0, Babel became modular (a pretty controversial idea at the time). This was a huge change that led to opt-in functionality (no defaults) and the concept of Presets and Plugin Options.
- As mentioned in his article, Sebastian joined Facebook in July 2015 and worked on the entire development of Babel 6 on company time.
6.3.13 Sebastian extracted our monorepo build/publish tools into what is now Lerna. (What’s funny is James rewrote it 3 times and I had to review everything)
- After this was around when both Sebastian and James got burned out on Babel, and a few contributors stepped up.
- We struggled to find direction and deal with the bugs/requests coming in but we got a lot of stuff done!
6.13.0 finally added Preset Options.
6.14.0 added a latest-preset that keeps up to date with the yearly JavaScript specification.
6.16.0 allowed changing out the parser or code-generator.
In August, we released Babili, a minifier based on Babel.
In September, we released the first version of babel-preset-env (read on for details).
After a year on Phabricator, we moved back to to GitHub issues thanks solely to @danez and his amazing (and underappreciated) work.

If you’re using Babel, let us know with a PR to our users page!

Now babel-core is downloaded over 5 million times per month and almost 60 million times total and used at huge companies like Facebook/Netflix/Airbnb and other OSS projects like React/Yarn.

Thanks everyone for your continued support! We want to continue acting as the foundation of the JavaScript toolchain: compilation, linting, minification, codemods, code coverage, etc.

Current Status

If you’re interested in helping out please check out the issues linked below!

Maintaining Babel plugins for each proposal in TC39 starting from Stage 0

TC39 stands for Ecma International, Technical Committee 39: it’s the committee that makes JavaScript.

@b0rk Short answers:

Who's there? Engine implementors, developers, a handful of academics and theorists, and @BrendanEich.
— Yehuda Katz (@wycats) November 30, 2016

Babel uses TC39’s concept of stages to categorize its experimental plugins. Users should be able to easily use features before they are all implemented in browsers in stage 4 of the TC39 process.

Babel is fundamental in the process given its place in the ecosystem: it is significantly easier for a developer to update a .babelrc file than a browser flag and much faster to write a Babel plugin than to implement the feature natively in the browser. This is the core of Babel.

But the proposals process involves significant iteration: proposals can change in syntax or even get dropped. Because TC39 meets every 2 months, plugins should be updated as least as often as each change in stage so that users can be in sync.

Early feedback to the proposal champion and committee is extremely valuable although it is recommended to use Stage 0/1/2 features with caution. Although companies like Facebook take advantage of these kinds of features, they have created codemods to allow easy change.

There isn’t enough time or resources to maintain each plugin, especially when there are spec updates.

Some transforms are simply out of date such as decorators. Logan had to port the previous spec babel-plugin-transform-decorators-legacy for Babel 6 and we haven’t had anyone able to rewrite it for the updated spec.
babel/babel#3473 - Async iteration proposal wasn’t merged for so long because we just didn’t have time to review it. By the time it was merged it had already moved from stage 2 to stage 3.

Next we’re going to be working with:

Relevant Issues:

Should we create a codemod for Stage X proposals at the same time as creating the actual transform?
Private Fields
Decorators Proposal

Check out thefeedbackloop.xyz for more info on TC39!

Maintaining other ecosystem plugins: JSX/Flow

Babel is vital to the React and Flow ecosystems, and we work closely with the relevant teams at Facebook.

React plugins, React preset
- These cover the main JSX transform, development plugins, and optimizations.
Flow plugin

Relevant Issue Labels:

babel-preset-env (“autoprefixer” for Babel)

JavaScript compilation is a moving target: There are yearly updates to the spec, browser vendors are constantly updating to that spec, and users may drop support for earlier browsers. At first glance, there doesn’t seem to be a fixed target for what we should compile our JavaScript down to.

The compat-table is updated constantly and is used for this preset.

This is where babel-preset-env comes in: it’s a Babel preset that automatically determines the correct Babel plugins to use based on the provided environments.

Its goal is both simplicity in use and efficiency in output: you only need to worry about your target environments to be able to take advantage of native code. The preset decides for you the required plugins.

Some example configs

Targeting Chrome 55 + last 2 versions of other browsers via browserslist

{
  "presets": [
    ["env", {
      "targets": {
        "chrome": 55,
        "browsers": ["last 2 versions"]
      }
    }]
  ]
}

Targeting the current Node.js version (uses process.versions.node)

{
  "presets": [
    ["env", {
      "targets": {
        "node": "current"
      }
    }]
  ]
}

Chrome 55 useBuiltIns + webpack 2

{
  "presets": [
    ["env", {
      "targets": {
        "chrome": 55
      },
      "modules": false,
      "useBuiltIns": true
    }]
  ]
}

import "babel-polyfill";

Out (different based on environment)

import "core-js/modules/es7.string.pad-start";
import "core-js/modules/es7.string.pad-end";

Relevant Issues:

Next big feature: apply the same idea of preset-env to polyfills as well babel/babel-preset-env#20 with corresponding PR in babel/babel-preset-env#56.
Using browserslist and PR
“Node.js versions support” in Browserlist
Publish runnable tests & browser data to npm

Linting via babel-eslint

ESLint doesn’t support new language features until they reach Stage 4 of the proposals process. For this reason we maintain babel-eslint (a custom ESLint parser) so you can continue to lint JavaScript with experimental syntax.

This project was one of the hardest projects to work on: because it is just a compatibility layer between Babel and ESLint there is inherently a constant need for updates when either projects update and a high risk of unexpected changes due to monkey-patching. It was unfortunate to get issues like babel/babel-eslint#243 or babel/babel-eslint#267.

To that end, we’d like to lessen the maintenance burden of this project by improving our scope and traversal interop with ESLint. It might even be interesting to be able to write ESLint rules using babel APIs or vice versa?

Relevant Issues:

Previous Linting APIs Discussion
Running smoke tests on ESLint
babel/babel-eslint#88 is still relevant now

Minification

Babili is our new Babel-powered minifier, enabling you to produce minified code while targeting the latest browsers.

class Mangler {
  constructor(program) {
    this.program = program;
  }
}
new Mangler();

Out

// ES2015 code -> Babili -> Minified ES2015 Code
class a{constructor(b){this.program=b}}new a;

Check out our blog post for more info.

Since it was recently released, we’re looking for some new contributors! There’s a lot of small bugs and things that could be improved for those looking for a new project to help out with!

Codemods / Refactoring / `eslint --fix`

A codemod is a tool-assisted code modification; a fancy find-and-replace.

If you wanted to change merge({}) to Object.assign({}) (and maybe later object rest) you might do a regex replace. But you don’t want to replace the other parts of the code that also might be called merge such as imports/exports, strings, comments, and local variables. To do it safely you’ll want something more powerful that only changes the specific code you need.

Although Babel already handles transforming code into other code, it doesn’t really care about the styling of the input code as a compiler. After using Babel with its default options to do a codemod, git diff looks really messy.

Enter Recast: a tool that preserves the formatting of unmodified code while also pretty-printing any new AST nodes.

In the screenshot above, the top-left pane is the input code and the bottom-right pane is the output code after the babel plugin is run. In this case it’s preserving the whitespace of the input code when possible.

By passing in Recast in the options, Babel can power the future of codemods.

.babelrc

{
  "parserOpts": {
    "parser": "recast"
  },
  "generatorOpts": {
    "generator": "recast"
  }
}

Run the relevant Babel transform(s) on the source code and overwrite it:

babel src -d src

This feature was just made possible so we’re looking forward to making it easier to use and seeing the transformations it can enable. Check out the 6.16.0 blog post for more info!

Other relevant projects: JSCodeshift, js-codemod, Lebab.

Relevant Issues:

Code Coverage / Instrumentation

We want to support tools like nyc and babel-plugin-istanbul.

Plugin Ecosystem

Thanks to our vibrant community, new plugins are constantly being created: whether it be a new way to write your css in jsx or rewire your tests.

Currently there are > 1200 babel-plugins on npm.

We’ve had some interesting discussions on how we can grow and support the plugin ecosystem. We could try to watch all the repos but that is obviously overwhelming.

It might be interesting to create some bots to automate a few tasks: create specific Babel plugins/ESLint rules for babel-plugins, write codemods to update API changes, and integrate plugins into our smoke test.

@jaredforsyth @reactjs My five minute POC ☺️ https://t.co/v74UFHsSJG pic.twitter.com/B3YwVWkH5g
— Henry Zhu (@left_pad) December 6, 2016

Should we create a newsletter for new/useful plugins?
How can we teach people about plugins and how to write them?
How can we make ASTExplorer better?

Documentation (this website!)

Docs contributions have definitely been lacking in the last year.

However just recently we’ve done a lot of awesome stuff:

@Daniel15 has been maintaining babel-standalone which we use in the REPL and has some automation when new releases get out.
@maxiloc added search functionality via Algolia via #977

We’ve also added new collaborators:

@STRML: Added Discourse to all github pages via #875
@xtuc: Added support for reading the README from the babel repo so we don’t have to sync 2 copies of docs via #990
@fredericmarx: Added support for a copy to clipboard button for code snippets via #998
@seedofjoy: Added a resize ability for the REPL via #1003

Some Ideas

All plugins should have examples. Can also embed RunKit or the REPL.
Update FAQ with common errors
API docs / make babel-handbook better

Relevant Issues:

The Future

NOTE: Everything below can be changed or dropped. Some might be already in the works and others are just suggestions that need a proper discussion/champion.

Priority should be determined on what the community needs: not because it would be nice to have.

Plugin API Changes

There is a lot of confusion around how plugins/presets interact regarding ordering. This results in bugs and issues with the config which require users to place plugins before/after others in a non-intuitive way.

We’re currently discussing API changes that could reduce the confusion. However, since this is a fundamental change to the core of Babel, it might take a while to figure out the best approach.

Versioning

Since Babel 6 we’ve used a “fixed” mode of versioning via Lerna. This is what allows us to release multiple packages at the same time all under the same version (if that package changes). This is nice because you don’t have to manually set a version for each package but everything moves together. The only time this could cause an error is when one on the packages makes a breaking change: then every package also will bump major versions.

This is explained more in babel/notes but we still need to figure out the best plan of action for the project.

What happens when we need to update a Stage 0 spec to Stage 1 and it’s a breaking change to the parser? Are we just going to bump the major version, wait to batch some changes up, or figure out how to do it via multiple versions of plugins?

Discussion Issue

Changing the Mindset Around Stage X Presets

My rule of thumb on how I decide what future features to transpile:
"Could I reasonably codemod this if it changes?"
Don't do it otherwise.
— Kent C. Dodds (@kentcdodds) November 30, 2016

Relevant Issues:

Should we rename the stage x presets to explain more that they are “experimental”

Speed

Performance is a feature! Other things can be more of a priority at times (bug fixes, spec compliancy, etc) but it’s still important in a few different aspects.

How can we reduce the size/time of install, especially for a project with multiple packages? (this is helped by yarn)
How can we parse faster?
How can we make faster plugins (and measure them individually)?
How can we generate the transformed code faster?
How can we generate code that runs fast in the browser (https://fhinkel.github.io/six-speed/)?

If you to read the compiled output and see issues, then report it and ask for help in making a PR!

Previous Issues:

Possible TypeScript Support?

Maybe Babel could learn to understand TypeScript syntax (like we do with Flow)? We could add a plugin to strip TypeScript types for better interop.

This would mean parsing TypeScript specific syntax and stripping it out. However TypeScript does have non-type syntax, so for things like enum we will would have to discuss more.

Use Type Information?

Integrate with a type system such as Flow/TypeScript to make optimizations. This just means that Babel should be able to gain the knowledge through those tools that an identifier arr is actually an Array or not.

There are a few plugins that actually do type checking: babel-plugin-typecheck and babel-plugin-tcomb

Previous Issue

Taking in a Dependency Graph / Operate Multi-file?

Then we could integrate with other tools like Webpack better. This would allow cross file transformations or whole codebase optimizations. The main reason for this would be for the minifier (being able to remove properties based on checking the usage across the whole application) or for example providing errors for missing/invalid import/exports.

Discussion Issue

Parser Errors

Better error messages from the parser like in Compiler Errors for Humans.

babel-eslint@7.1.1: now adds the code frame when there's a parser error! pic.twitter.com/yoxRpGXq5E
— Henry Zhu (@left_pad) November 17, 2016

It is obvious that we all want to see helpful errors!

We can do better inference/guessing on user intention to prevent vague errors. Let us know in what cases that happens!

Relevant Issues:

`babel-init`

Basically a way to set up Babel more easily like create-react-app does.

Set up a .babelrc from scratch, prompt with questions

Possible Idea:

Ask about target environments (browsers, node) and pass to babel-preset-env
Ask about experimental features (add specific plugins)
Update the babel npm package to do something again: Make it the default/opt-in/opinionated babel that Babel 5 was. It can default to using env and say the latest 2 browsers (without any config).

Relevant Issues:

Run tc39/test262

test262 tests conformance to the continually maintained draft future ECMAScript standard found at tc39.github.io/ecma262, together with any Stage 3 or later TC39 proposals. It is maintained by Tom Care (@tcare) with significant contributions from many in the ECMAScript community.

Running the official spec tests against Babel can make sure we comply to the spec or at least know when we don’t. We’ll want to figure out how to do filtering on things we can’t compile (proxy, TCO, etc) and set up an easy way to check failing tests and file issues and PRs for them.

Relevant Issues:

Smoke/Integration Tests

It would be useful to either have a reverse Greenkeeper or to run tests with master branch of Babel so that we can catch any major regressions before any release (node has the citgm project for this). In theory we would want to take the biggest open source projects that use Babel and run their tests.

motiz88/babel-smoke-tests is a good start! It would also be great if there’s already something like this out there!

Program Analysis

Program Slicing

There was a great talk by Alan Shreve called “Idealized Commit Logs: Code Simplification via Program Slicing” which inspired @kentcdodds to try it out in JavaScript via slice-js.

The general idea is that we have a lot of tools to help us write code but not a lot for helping us understand/read code. You can think of code-slicing as a form of targeted dead-code elimination.

A program slice basically cuts away from the source code the code that isn’t used for a test case that you run. If there are lots of if statements and loops that aren’t run during your usecase then it won’t show up in the program slice.

Semantic (AST aware) Grepping tool?

Similar to graspjs, I think it would be interesting to be able to do a find-replace with the input being an AST. It would allow us to create other analysis tools: the ability to find all IIFE’s in our code, the number of times a method is called, or even how many Classes we have in our codebase.

`babel --settings`

This command would print out all info (also when erroring). It would also include performance metrics on how long each plugin takes.

Discussion Issue

Parser Unity

There have also been some discussions around parser/AST unity, in TheLarkInn/js-parser-discussions and previously with ESTree.

Unfortunately with Babel 6, we have “forked” and have a few differences in our AST than ESTree. Babel aims to support stage x features while other parsers may only want to support stage 4 features. We all might prioritize certain things more than others regarding spec compliancy, performance, stage x features, error messages, extensibility, releases, etc. However it’s important for us to be open to breaking changes that may lead to better interop and a better community.

Sweet.js Interop?

Previous issue. Maybe we can just figure out how to have better interop instead?

Node.js Support

Should we drop support according to the EOL of Node.js versions? How long should we wait to do this in general?

Do we want to continue to support our users who haven’t updated yet?
There are certain transforms/PRs that are blocked by this, due to tools that have also dropped older versions.
Many other build-time projects like ESLint have done so already.
Are we going to make a major version just for this or plan out other changes in addition?
Discussion Issue

Babel 5 to 6 transition / Upgrade Paths

Babel 6 was really difficult for the community to upgrade to. The initial release was a bit rushed. Although we did have a 6.0 release post, a setup guide soon after, a even a tool (now deprecated) to help with the transition it was still difficult for users to understand the changes.

There are still a good amount of users on Babel 5 that we don’t want to leave behind. What can we do to help them upgrade? What steps do we need to take in the future to make sure the same thing doesn’t happen with a Babel 7? Are there other projects/communities we should be reaching out to and helping?

Relevant Issues:

ember-cli Babel 6.0 Issue needs help!
Any others?

What else?

Anything else not already brought up here? Please send us a tweet @babeljs, a message on our slack (join at https://slack.babeljs.io/, comment on this post, or create an discussion issue in our repo!)

Are there projects or communities we should partner with more? How can we make the contributing experience more welcome? What can we do to make the development process more transparent?

Community

Old Issues:

You might think that as a project gets more widely used that more people show up to help out. But like most OSS projects that aren’t backed by a company, there is a constant issue with maintenance and sustainability; people get burned out, move on to other cool projects, or get busy with work/family/etc.

Like James describes in Dear Javascript, the current Babel team is pretty small.

Babel isn’t a company, a special team at Facebook, or corporate-funded OSS project. It’s a community-driven effort currently held up by a few people and we want that to grow.

So if you’re interested in contributing to a tool you use, we’re hoping this could be the one!

What issues should I look at or contribute to?

Many of our projects have both beginner-friendly and help-wanted labels. You can also check out discussion.

Team

Our core team is:

And just in the last 3 months a lot more collaborators:

Babili core team:

As mentioned above we have a lot of website collaborators:

Inactive but still a resource:

How can I contact the team?

GitHub

For bug reports/PRs you can check our repositories.

Twitter

You can ping us on Twitter with @babeljs - or mention us individually.

I myself joined Twitter to be able to talk with users and help out. Being able to post new features and changelogs is really useful and can help give us feedback!

Slack

We have a relatively active community on there!

You’ll find a lot of awesome community members willing to help such as Jordan Harband, @ljharb, Diogo Franco, @kovensky, Jimmy Jia, @taion, Denis Pushkarev, @zloirock and more!

If you haven't joined our slack yet: please join at https://t.co/h3m7l9jkrg. Check out development/plugins to see what's up! pic.twitter.com/f1CKaV8G6G
— Babel (@babeljs) October 31, 2016

If you just have questions join #discussion and if you want to help or listen in check out #development.

We try not to discuss in private if there’s no need to: I myself usually post the issues/PRs I’m working on for people to review and talk about.

Other

How else can we interact with the community? Should we go and start meetups, go to conferences, or manage hackathons?

How can we make Babel sustainable? Should we setup a Open Collective or seek a foundation? Should we pay for a project manager?

Let us know your thoughts! What do you want out of Babel?

See typos/issues? Please send a PR or comment on babel/babel.github.io#1014

If anything we want to let you know that many of us got our start with Babel in order to learn JavaScript rather than helping because we already knew it. Personally, I knew nothing about compilers and had just learned what ES6 was when I found the project. I got here because of a tiny bit of curiosity and some encouragement from a lot of people. I want to carry that forward and hope that we can all succeed together.

Thanks so much for reading!

Henry Zhu (@hzoo) (@left_pad)

Thanks to way too many folks for their review and thoughts: @DrewML, @mrjoelkemp, @kentcdodds, @existentialism, @jdalton, @gaearon, @nolanlawson, @jayphelps, @montogeek, @TheLarkInn, @jasonLaster, @benjamn, @addyosmani, @Daniel15, @loganfsmyth, @gr2m, @mathiasbynens, @chicoxyzzy, @bvaughn, @bcoe.

6.19.0 Released

Wed, 16 Nov 2016 11:00:00 +0000

object-rest-spread works standalone and a few new plugin options APIs were added!

v6.19.0 Summary (2016-11-16)

🚀 New Feature

#4755 Make object-rest-spread work as an independent plugin. (@hzoo)

This rewrite fixes a long standing issue where the object-rest-spread plugin was depending on 2 other plugins to compile RestProperty properly.

This fix important given the assumption that plugins should be independent and is vital for the use of babel-preset-env since new environments support destructuring natively.

const { a, ...b } = c;

Out

const { a } = c; // remove the `...b`
const b = _objectWithoutProperties(c, ["a"]); // use the helper

It’s interesting to see all the places where you can destructure!

RestProperty

function a({ b, ...c }) {} // Parameters

const { a, ...b } = c; // VariableDeclaration

export var { a, ...b } = c; // ExportNamedDeclaration

try {} catch ({a, ...b}) {} // CatchClause

({a, ...b} = c); // AssignmentExpression

for ({a, ...b} of []) {} // ForXStatement

SpreadProperty

var a = { ...b, ...c } // ObjectExpression

#4544 Add the spec option to "transform-class-properties". (@motiz88)

Class properties will use Object.defineProperty instead of a simple this.x = y. Static fields are will use value: undefined even if they are not initialized.

Usage

{
  "plugins": [
    ["transform-class-properties", {
      "spec": true
    }]
  ]
}

class Foo {
  static bar;
  baz = 'guy';
}

Out

var Foo = function Foo() {
  _classCallCheck(this, Foo);
  this.baz = 'guy';
};

Out w/ "spec": true

var Foo = function Foo() {
  babelHelpers.classCallCheck(this, Foo);
  _initialiseProps.call(this);
};

Object.defineProperty(Foo, "bar", {
  enumerable: true,
  writable: true,
  value: undefined
});

var _initialiseProps = function () {
  Object.defineProperty(this, "bar", {
    enumerable: true,
    writable: true,
    value: foo
  });
};

#4836 Add path utilities path.isAncestor and path.isDescendant. (@boopathi)

We’ve added 2 similar “ancestry” path methods to path.findParent:

Usage

let programPath, numberPath;
traverse(ast, {
  Program(path) { programPath = path; },
  NumberPath(path) { numberPath = path; },
});

programPath.isAncestor(numberPath); // true
numberPath.isDescendant(programPath); // true

#4835 Add clearCache and clearPath as separate APIs under traverse. (@boopathi)

Usage

traverse.clearCache(); // clears both path's and scope cache
traverse.clearCache.clearPath();
traverse.clearCache.clearScope();

#4827 Add jsonCompatibleStrings option to babel-generator. (@kangax)

Usage

{
  "generatorOpts": {
    "jsonCompatibleStrings": true // defaults to false
  }
}

#3547 Added flowCommaSeparator to babel-generator. (@sampepose)

Usage

{
  "generatorOpts": {
    "flowCommaSeparator": true // defaults to false
  }
}

Currently there are 2 supported syntaxes (, and ;) in Flow Object Types. The use of commas is in line with the more popular style and matches how objects are defined in Javascript, making it a bit more natural to write.

var a: { param1: number; param2: string }
var a: { param1: number, param2: string }

#3553 Add t.isNodesEquivalent. (@hzoo)

Usage

assert(t.isNodesEquivalent(parse("1 + 1"), parse("1+1")) === true);

#4789 Support stage-2 import() as contextual import in transform-es2015-modules-systemjs. (@guybedford)

You’ll want to add the stage-2 preset or explicitly include babel-plugin-syntax-dynamic-import (not enabled by default).

export function lazyLoadOperation () {
  return import('./x')
  .then(function (x) {
    x.y();
  });
}

🐛 Bug Fixes

#4830 Will print the shorter of the NumericLiterals if using the minified option. (@shinew)

Input

5e1;
5e4;

Output

50;
5e4;

#4832 Fix transform-es2015-modules-systemjs to ensure consistent modules iteration. (@guybedford)

import "2"; // should be imported first
import "1"; // second

#4813 Fix binding kind of destructured variables relating to transform-react-constant-elements (@STRML)

Fixes an issue with destructuring parameters being hoisted incorrectly.

Input

function render({ text }) {
  return () => (<Component text={text} />);
}

Output

function render(_ref) {
  let text = _ref.text;
  var _ref2 = <Component text={text} />;
  return () => _ref2;
}

🌏 Committers: 10

Boopathi Rajaa (boopathi)
Guy Bedford (guybedford)
Henry Zhu (hzoo)
Juriy Zaytsev (kangax)
Moti Zilberman (motiz88)
Sam Pepose (sampepose)
Samuel Reed (STRML)
Scott Stern (sstern6)
Shine Wang (shinew)
lion (lion-man44)

Check out Github for the whole changelog!

Babel

Planning for 7.0

Upgrading

Re-iterating Project Goals

#4315 Drop support for unmaintained Node versions: 0.10, 0.12, 5

👓 Proposal Updates/Spec Compliancy

Philosophy (Proposals: spec, loose, default behavior)

Stage 3: Class Properties (from Stage 2)

Stage 3: Object Rest Spread (from Stage 2)

Stage 3: Optional Catch Binding (new)

Stage 3: Unicode Property Regex (new)

Stage 3: BigInt (new, unfinished)

Stage 3: Dynamic Import (from Stage 2)

Stage 2: import.meta (syntax only)

Stage 2: Numeric Seperators (new)

Stage 2: Decorators (from Stage 1), still WIP

Stage 2: function.sent (new)

Stage 2: export-ns-from

Stage 1: export-default-from

Stage 1: Optional Chaining (new)

ES2015: new.target

🚀 New Feature

.babelrc.js

TypeScript

“Pure” Annotation in specific transforms for minifiers

😎 Other Breaking Changes

Removed babel-preset-flow from babel-preset-react

Integrations

Meta

#5218 Remove babel-runtime from our own Babel dependencies

#5224 Independent Publishing of Experimental Packages

TODOs?

💀 Possible Deprecations

Deprecate the “env” option in .babelrc

Deprecate ES20xx presets

🤔 Questions

Deprecate/Rename/Remove Stage X presets

Using npm Scoped Packages

external-helpers, transform-runtime, babel-polyfill

What’s next?

Project Sustainibility

Future

Thanks!

Zero-config code transformation with babel-macros

Introducing babel-macros 🎣

Conclusion

Contributing to Babel: Three Lessons to Remember

1. Yes, communication is important

2. Where snapshot testing falls short

Arguments deoptimized when shadowed in nested function

Input code

Expected vs. Current Behavior

What’s going on here?

Trying to fix it

The Chromium debugger is “fun”

The actual problem?

So why do we use snapshot testing then?!

3. Team meetings!

Time zones

Where to next?

More about Karl

Personal Experiences at Babel #1 — A PR with Unusually High Number of Reviews

Footnotes

Outro

Babel and Summer of Code 2017

What is it?

Google Summer of Code

Peeyush Kushwaha (India)

Karl Cheng (Australia)

Rails Girls Summer of Code

Kara de la Marck (London)

Emma Deacon (London)

Why?

Thanks

Upgrade to Babel 7 (WIP)

All of Babel

Option parsing

Resolving string-based config values

Path-based only and ignore patterns

Babel’s CLI commands

Stage 2: `import.meta` (syntax only)

Stage 2: `function.sent` (new)

ES2015: `new.target`

`.babelrc.js`

Removed `babel-preset-flow` from `babel-preset-react`

#5218 Remove `babel-runtime` from our own Babel dependencies

Deprecate the “env” option in `.babelrc`

`external-helpers`, `transform-runtime`, `babel-polyfill`

Introducing `babel-macros` 🎣

Path-based `only` and `ignore` patterns

`babel-core`

`babel-traverse`

#5236 `transform-es2015-block-scoping`: Add option `throwIfClosureRequired` to throw on slow code. (@spicyj)

#4812 `transform-react-constant-elements`: Support pure expressions (@STRML)

#5288 `babel-preset-flow`: Add new preset (@thejameskyle)

#5230 `babel-traverse`: Add extra sibling methods (@chitchu)

#5298 Fix loose `transform-es2015-for-of` with label. (@jridgewell)

#5153 `transform-react-constant-elements`: Hoisting fixes (@STRML)

#5143 `transform-react-constant-elements`: Fix `PathHoister` hoisting JSX member expressions on `this` (@STRML)

#5030 `transform-do-expressions`: Prevent multiple return statements in a loop when replacing expressions. (@existentialism)

#5260 `babel-register`: Fix a TypeError with the cache. (@xtuc)

#5206 `babel-traverse`: Deopt evaluation of undefined with a local binding (@boopathi)

#5195 `babel-plugin-transform-runtime`: Don’t compile certain symbol properties. (@taion)

#5258 `babel`: Check if it is installed globally and displays correct cli message. (@xtina-starr)

#5270 `babel-generator`: Emit parens for await of ternary expressions. (@erikdesjardins)

#5193 `babel-generator`: Fix missing parens when `FunctionExpression` is a tag in a template string. (@existentialism)

#5235 `transform-es2015-modules-commonjs`: Limit export node default assignment stack size #4323. (@mattste)

#5255 `babel-generator`: Use `trim` instead of `lodash/trimEnd` for codegen performance (@jwbay)

#5050 `babel-traverse`: Rewrite `Hub` as an interface (@yongxu)

Codemods / Refactoring / `eslint --fix`

`babel-init`