Add ES6/ES2016 support using Babel

[addyosmani]

The core team would like to propose adding in support for ES6 via Babel to Web Starter Kit ✨ We would like as much as possible for this to be a seamless change that doesn't introduce overhead for our existing ES5 user-base. Timeline for the change is for 0.6.0/0.7.0.

This is a natural progression after the project Babel-ified our Gulpfile.

How

There are a few approaches for this we can take including making this a default for all users or an option. Some off the top of my head:

1. Make Babel the default. Our build pipeline works fine for both ES5 and ES6 source without the end-user needing to do anything. It may slightly alter the final ES5->ES5 output due to Babel's transformations and we'll want to do some research on any gotchas here.
2. Make Babel opt-in. We decide on an approach and make it a simple case of commenting/uncommenting a line of code or a Babel specific task. In Adding optional ES2015 support via Babel #739, one option explored is removing "only": "gulpfile.babel.js" from the .babelrc config file.
3. Make Babel extension specific. Support it by default, but only pick up files with an .es6` or similar extension so you're separating your ES6 and ES5 build pipelines.

Other tooling

There's also consideration we'll want to make around the supplementary tooling here, like linting and code-style checking.

Linting and style checking

I personally prefer using JSCS 2.0 (with the esnext option) + JSHint for most of my projects but ESLint has also been gaining ground in the Babel community and is worth considering too. @sindresorhus suggested we go for the latter. I'm open to us discussing our options.

Source Maps

We will want to ensure our Source Maps setup updates accordingly to support the changes in workflow if any are required.

Work in progress 💄

@nicolasgarnier has started a PR that adds optional support over in #739. We're happy to evolve it based on feedback from the community.

Further notes

For now, we have not discussed adding in support for Browserify/Babelify to tackle bundles. Imo, it makes more sense for us to gently introduce an ES6 workflow, observe the needs of our users and then figure out the next steps for supporting their tooling needs. Throwing the kitchen-sink at them might not be best :)

[seanislegend]

Great to hear. I am slowly adding ES6 support into my projects and I currently have taken the third approach you have suggested. To cut the Babel build time (and any potential unwanted ES5 transformations) I am saving my files as 'x.es6.js' and so far this is working really well.

One side-note on that; I've had to add an intermediary step into my RequireJS optimisation task to build ES6 files to a temp directory, then move to my dest directory where I will then optimise. Bit of a hacky workaround for now, until I can spend more time on it. Not sure if you will come up against anything similar but would be great to hear some thoughts on this if you do.

[sindresorhus]

Regarding linting and style checking. The reason I prefer ESLint is that it covers all the JSHint rules and most of the JSCS rules in one tool that is IMHO easier to use, especially when you take advantage of shareable configs. You could go with the eslint-config-xo-space shareable config which comes with sane defaults, if you don't want to deal with all the ESLint rules. Or go all in and use XO with the space option.

[gauntface]

I've taken the same approach as @seanislegend in terms of file naming but largely because I needed a way of passing everything through browserify and babel.

If you named everything *.js, I'm not sure how you would babelify the files if you only want specific files to be produced into js files in the final build.

I'm impartial to ESLint vs JSHint + JSCS. ESlint had some nice features, but nothing I could see that made me really want to fight for using it.

[andylima]

The reason I prefer ESLint is that it covers all the JSHint rules and most of the JSCS rules in one tool that is IMHO easier to use (...)

I prefer ESLint as well, mainly for the reasons stated by @sindresorhus