Moving your Team and Project to ES6

How do you safely move your team to using ES6?

1. Convince the team/boss/stakeholders that it's time to move to ES6

The points in this article might help.

2. Decide what you're going to use

Are you going to use a transpiler like Babel or a shim? If using Node.js are you going to use the --harmony flag? There are plenty of articles that discuss this.

3. Start using ES6

Most teams will have at least one person who wants to use the new syntax. This is how these developers should introduce ES6 to the rest of the team.

Training? That's one way. Another is to cross-train each other on a code base that you're already working on.

Let's say that you wrote some ES5 code like this:

handleChange(name, e) {
  var change = {};
  change[name] = e.target.value;
  this.setState(change);
}

and you decided that you'd rather use ES6 syntax like this:

handleChange(name, e) {
  var change = {
    [name]: e.target.value;
  }
  this.setState(change);
}

The better way to use the ES6 syntax is to tag it with the name of the new feature like this:

handleChange(name, e) {
  var change = {
    // ES6: Destructuring, computed property keys
    [name]: e.target.value;
  }
  this.setState(change);
}

A developer looking at the ES6 comment should be able to copy/paste the text into a search engine and find a reasonable list of articles that deal with the feature.

4. Teach in the Pull Request Review

Now when you do a Pull Request on your changes message the rest of the team that there are labeled ES6 features.

I've found that this has the extra bonus of having more developers want to review your code because they know that they're going to be learning something new about ES6 during the review process.

Your team are already contributing to and editing a code-base that they're familiar with so the ES6 usage that they're learning is not contrived. It's real world.

5. Remove the ES6 comments

The comments labeled ES6: are there for training purposes. After a period of time you may want to remove them. This is easy to do in a search and delete of this type of comment in the code base.

If you have a lot of non-ES6 developers continually joining the project then you might not want to do this. You can also tag the repository before removing the comments so others can checkout that tag and read the comments.

You might also elect to start dropping comments for the easy-to-understand and common ES6 features and keep them in for the more complex scenarios.