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.
- 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?
@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.