Skip to content

Instantly share code, notes, and snippets.

@addyosmani

addyosmani/draft.md

Last active November 3, 2017 11:32
Show Gist options
  • Star 5 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save addyosmani/bb6e2939f943226e68e87396c4931040 to your computer and use it in GitHub Desktop.
Save addyosmani/bb6e2939f943226e68e87396c4931040 to your computer and use it in GitHub Desktop.
Download ZIP
Babelon - smarter transpilation targeting for Babel
Raw
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?
@hzoo
Copy link

hzoo commented Apr 24, 2016 •
edited

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment