In the spirit of supporting JavaScript development for Atom packages,
this adds default support for es.next transpilation support in the way
that Atom already has default support for CoffeeScript transpilation.
There are many new features in ES6+ that make JavaScript development
easier and more enjoyable, particularly in terms of support for async code.
For reference, this was a much faster way to iterate on this than running `./script/build`
each time:
```
cp /Users/mbolin/src/atom/static/index.js /Applications/Atom.app/Contents/Resources/app/static/index.js
coffee --output /Applications/Atom.app/Contents/Resources/app/src --compile /Users/mbolin/src/atom/src/esnext.coffee
```
Run the following in the console to see how warm the cache was after startup:
```
global.require('../src/esnext/').getCacheHits()
global.require('../src/esnext/').getCacheMisses()
```
The goal is to allow the editor’s styling to be overridden as follows:
atom-text-editor {
background: black;
color: white;
}
If we retain these classes, themes will continue to style the root
element of the editor and destroy the ability to style the editor in
this way. You would instead have to do the following:
atom-text-editor::shadow .editor {
background: black;
color: white;
}
This is way less intuitive and confusing for people.
Trying to style both modes of the text editor with the same style sheet
is proving to be more trouble than it’s worth. This prepares the shadow
DOM style sheet to diverge more radically to enable the background color
to be overridden from the outside more easily.
This prevents the need for a :host pseudo-class in the editor CSS which
breaks linting. It also fits selectors targeting the host element in a
more intuitive spot in the cascade.
Themes aren’t applying correctly and there are issues with mini editors
but this basically works. I’m leaving the .editor node in the shadow
DOM for theme compatibility and because React still wants to render
into a wrapper element.
