Current coverage is 85.54%

Merging #3476 into master will decrease coverage by -0.27% as of fd73893

@@            master   #3476   diff @@
======================================
  Files          197     197       
  Stmts        12227   12244    +17
  Branches      2521    2530     +9
  Methods          0       0       
======================================
- Hit          10493   10474    -19
- Partial        522     552    +30
- Missed        1212    1218     +6

Review entire Coverage Diff as of fd73893

Powered by Codecov. Updated on successful CI builds.

Would be super nice if it could just adhere to what's in the engines field in package.json. That way you wouldn't have to specify anything manually.

@sindresorhus is that only for node? Could def work as a default if it's there.

@hzoo Only for Node.js yes.

I'd like to chime in here as I was planning to implement this feature until I noticed this issue. I've pretty much got it all planned out, just need to actually build it. Basically it would go:

1. Each package would have a mapping in package.json of each browser and or target version in which this feature was released natively. For example, arrow functions (https://github.com/babel/babel/tree/master/packages/babel-plugin-transform-es2015-arrow-functions) would have the following added to its package.json.

"browsers": {
  "chrome": 45,
  "firefox": 22,
  "ie": false,
  "edge": true,
  "safari": false,
  "opera": 33,
}

Based on the following links:

• Chrome: https://www.chromestatus.com/features/5047308127305728
• Firefox: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
• IE/Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/status/arrowfunctiones6
• Safari: http://trac.webkit.org/changeset/185989

When babel is ran, it would work similar to autoprefixer, in which you can target individual browser versions, or you can do "last 3 versions", etc. It would then validate the browser version in each package, and determine whether to run the transformer or not. If a browser version is false or undefined, then the feature is not supported natively. If the browser version is true, then it does support it, but we do not know which version (mainly Edge).

2. Where to get all the data? This is easy as each vendor has a status page:

• Chrome: https://www.chromestatus.com/features
• Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/status/
• Firefox/Other: https://developer.mozilla.org/en-US/

We also have kangax and caniuse.

• https://kangax.github.io/compat-table/es6/
• http://caniuse.com/

3. What about mobile? Well, mobile is super tricky, as mobile chrome and desktop chrome are not always in sync and does not always support the same version, etc. I honestly don't have an answer to this besides building separate desktop and mobile bundles, in which all the transformers are ran for mobile. Open to suggestion on this one.

4. This would also work nicely with presets, for example: babel-preset-chrome-latest, etc.

I would really love this feature, as I currently work on internal tools at my company, in which we only have to support Chrome 40+. This feature would lower our filesize and tech debt considerably.

This will be especially important since V8 has almost 100% ES2015 support: http://v8project.blogspot.se/2016/04/v8-release-51.html

node.green also has tons of info.

As a node module author who wants to write for node 5 but has to support 0.10-6 and electron and NWJS. I support these efforts and hope they include non browsers too.

It might be worth adding a the ability to just set latest for browsers, or perhaps -2 for "latest - 2 versions". This allows us to not worry about updating this setting on a regular basis, but still set some kind of definition around browser support.

Most browsers are evergreen now, so depending on your customer base, adding support for anything more than latest may just be a matter of allowing people a little time to get the latest update (I realise this may be different in the corporate world or other demographics).

Overall I think this feature will be great, it'll cut down on the size of exported code and will make pages more performant (no feature detection in some cases, less polyfills).

@mrmckeb for sure that would be a useful feature (given this is basically autoprefixer for babel), just need to update when new browsers come out

What about using https://github.com/ai/browserslist instead of specifying each browser version?

// .babelrc
{
  presets: [
    ["latest", {
      browsers: 'last 1 version, > 10%',
      browsers: ['last 1 version', '> 10%'], // alternative proposal
      node: 5
    }]
  ]
}

Yeah that sounds great - cc @ai if you have any tips or can help with this effort

@hzoo sure, Autoprefixer, cssnext and Babel will take same browsers from browserslist config. Browserslist API is simple. It load config automatically — just send file path to path option.

Yeah Babel is a bit different since we will also need other js environments like node, electron, etc. I think we can start with browsers as a proof of concept though since not sure how we want to do it.

I could add Electron and other env’s support to browserslist.

Good thing you guys pinged this as I was itching to try it out. Has any work been done on this yet (besides this PR)?

Not that I know of? If anyone knows about anything please send a link (if it makes it easier to contribute we can move this to another repo and then merge it in afterwards)

Sorry, was busy doing other stuff (also merge preset options so this will actually work) but would like to start if we have a better idea of how it will work - it sounds like we can break it down into

• what should the configuration options look like? Just an key with an array?

{
  presets: [
    ["env", {
      browsers: ['last 1 version', '> 10%']
    }]
  ]
}

• How can we automatically get the data from @kangax tables, caniuse (which doesn't seem to actually have much js support in it)
  • I don't know how easy that is, so just make it easy to add the data manually since it's not going to change per version
• How to map the data ^ to the actual babel transforms
• Simple function to do least common denominator of transforms
• an option to specify what target of javascript (es2015,etc, or if stage-3, etc)

Other Features

• other cool things like using "engines" in package.json for node, etc

I built something like this with auto-babel. It's currently working for node, and I had previously used sauce labs to run tests for browser support. I haven't updated it to work with babel 6 yet. I found the kangax raw data unsuitable for browserslist matching and caniuse missing JS feature support completely.

https://github.com/kangax/compat-table doesn't have raw data yet. There is an issue compat-table/compat-table#785

Probably better as a separate repo, so moving to https://github.com/babel/babel-preset-env

I just stumbled across this post. I've also been working on a preset with this support.
https://github.com/sdkennedy/babel-preset-target

Ok actually moving this PR to https://github.com/babel/babel-preset-env (when it's more stable we can add it back). Will need to transfer the comments we have here over there (and if anyone wants to add issues feel free)

Sounds like it would be good to combine efforts with @jakepusateri's https://github.com/jakepusateri/auto-babel that has auto node support and @sdkennedy's work on https://github.com/sdkennedy/babel-preset-target

So https://github.com/babel/babel-preset-env has a basic implementation now - 0.0.1.

Data is probably wrong but that can always be updated

@hzoo This rocks, I used to use both babel-preset-modern-browsers and babel-preset-modern-node and it looks like this could replace both. Thanks!

We'd appreciate the help on preset-env to make it more robust but of course feel free to continue working on other presets as well! Hopefully we can work together on this since there seems to be a lot of edge cases to handle

cc @christophehurpeau @michaelcontento @jakepusateri

babel-preset-modern-node has now been deprecated in favor of this. Great work and keep on rockin! 👍

Just FYI https://github.com/babel/babel-preset-env is 1.0 now! Has a lot of new stuff

• electron,
• auto node based on process
• can modify polyfills based on env
• debug mode (log out plugins used)
• etc