Babelon - smarter transpilation targeting for Babel

draft.md

Inspiration: https://twitter.com/samccone/status/722826060161617923

Modern JavaScript engines support an increasing intersection of ES2015 (and above) features which simply don't require transpilation in order to be successfully parsed and executed. This project lays out a proposal for a lightweight Autoprefixer-style tool that takes as input a target set of browsers (A) which check against a source of data for supported ES features (Kangax ES6 tables (B) (see https://github.com/kangax/compat-table/blob/gh-pages/data-es6.js) and generate a mapping to Babel transforms for features requiring transpilation that are not supported (C) or not fully supported (e.g behind flags or staged but not flipped on to default).

To avoid the introduction of even more configuration files, this tool could piggyback off of some config we could store in an existing .babelrc file or package.json to read in the list of browsers being targeted.

This tool could be implemented in a few different ways. It could exist as a one-time operation that simply runs against your .babelrc file / wherever you're specifying targets and npm install the necessary presets to your package.json / setup anything else needed. It could also be implemented as a hook of some sort that is run before Babel is in case this target configuration changes.

The overall goal is to avoid the need to transpile every feature under the sun, especially in cases where only a small subset are required but the end-user doesn't wish to manually 1. investigate what their target browsers support and 2. set these presets up themselves manually - something that would could be quite tedious.

Questions

• What's the most sensible way to manifest this tooling in someone's Babel workflow?
• Is there prior art that solves this problem in the OSS community right now?
• Is the above useful? Would it make more sense to add in another step that parses your source AST, figures out what features being used aren't supported in your target browsers and sets up the necessary presets for you? V2?

As a user (developer), the LCD is the friendliest option to use. Really eager to see how this tool will pan out; it is one of my concerns before switching to ES2015 development.

Simplest solution + zero config seems desired. No build step preferred. Therefore it seems tool should:

1. Setup all plugins for your target env (even if you're not yet using the feature) that represent LCD of host environments (e.g. All <=ES7 features for Chrome only).
2. Store those plugin set in .babelrc. This means this tool needs to add missing plugins, remove unneeded plugins, and leave alone the plugins that are orthogonal (like jsx or whatever).
3. be a simple one time use CLI tool.

Reasoning:

1. Trying to be smart about which plugins to add is going to introduce pain to devs when they try to use newer features. Babel won't tell them which plugins are missing. Sure, our tool could then be invoked again to figure out which plugin is missing, but it seems like an unnecessary burden for devs.
2. Introducing our tool into the build process seems like unnecessary time spent in building to optimize for rare event a dev uses a new feature they haven't before.
3. Building multiple bundles broken out by UA leaves devs with new problem to solve: how to conditionally load those bundles by UA. Unless we're planning on building that too (which I'm not!), seems like dead end.

Lastly, I'd like to say that in an ideal world, this would really be what a babel --init command should do. We should make sure this isn't in the works already.

One thing I failed to mention, the MVP I laid out above also means the "install" use case (setting up Babel for first time) becomes same operation as "update" (choosing to drop a browser and/or choosing to move from es6 to es7).

@mikesherov I like the expansions in 2. (in your first list) on this tool needing to both add missing plugins and remove unneded plugins. This would greatly help reduce developer overhead for any further clean-up being needed. I also strongly agree in 3. (in your second list) being overkill, particularly when we can offer a useful solution if we stick to the high-level simplest option we appear to be on agreement needs to be built.

I would also love to see this baked into Babel by default rather than us being yet another add-on tool. Perhaps @thejameskyle and @kittens have some thoughts on this. I would also understand if their preference was we proved the usefulness of this first before trying to roll it into Babel.

/cc @thejameskyle @hzoo

aside: I don't think mentioning actually sends a notification in a gist right?

Reading through everything ^ now but just commenting we do have an issue about making a babel --init or babel-init and want to do this. I also made a PR for discussion about supporting an environment either through a preset or potentially as part of core babel/babel#3476.

If anyone wants we could also discuss in the PR or in our #development room on https://slack.babeljs.io/

https://github.com/babel/babel-preset-env