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
.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?
Would you define your target browsers and and compile to the lowest common denominator of features? E.g. if all your target browsers supportes ES2015 classes, no need to transpile them. Or would you create a module for each target browser and load them according to user agent?