[gaearon]

Proof of concept for #892.
Doesn't work with ejecting yet.

Both autoprefixer and Babel are driven by a config like this in package.json:

  "browsers": {
    "development": [
      "last 1 chrome version"
    ],
    "production": [
      ">1%",
      "last 4 versions",
      "Firefox ESR",
      "not ie < 9"
    ]
  }

Currently I throw if it doesn't exist since I could generate a reasonable config by default (e.g. "last two versions" for development) in new projects and ask old projects to include it during migration. In a way this would be "configuration" but actually sensible one. I don't have a strong opinion here though.

[gaearon]

TODO: this likely requires switching to Babili. https://github.com/babel/babili
Because otherwise targeting too modern browsers in prod would crash Uglify.

[hzoo]

Similarly had an issue with webpack 1 since it's using an older version of acorn for async - forgot about that (babel/babel-preset-env#66)

[ai]

Note, that I am planning to add package.json support to Browserslist in next month. But I will use browserslist key.

The only issue with this CRA browsers key, that other tools added by user (Stylelint, doiuse, cssnext) will not get it. But CRA feature anyway will be faster than Browserslist fix, so we could start from it and then move to browserslist config key (I prefer global standard instead of CRA-only).

[gaearon]

My only concern with browserslist is that we still need a way to separate development from production configuration. If it will support this, I’m happy to use it.

[gaearon]

@hzoo

Alternatively we could add uglify and webpack targets to document their minimally supported environments.

[hzoo]

Yeah totally true, didn't even think of that! Could just alias it to node 0.10/0.12 although diff for webpack 2

[gaearon]

Another todo: make sure builds are reproducible
https://twitter.com/brian_d_vaughn/status/808143454739959808

[ai]

development/production environment are planned too with same ETA 😊

[gaearon]

Sounds great. This is a bit of a longer term project so I’m in no rush. It’ll take a while to work out most issues and get this to a stable state.

[lydell]

Please enlighten me! Why different browsers in development and production? Is it because of easier-to-read compiled code? What about when I need to fix those nasty IE 11 or Safari 9 bugs (which require certain vendor prefixes, for instance)?

[ai]

@lydell I asked for feedback in Autoprefixer twitter. Maybe some user have good use cases for environments (maybe not only development/production).

[gaearon]

I think it's up to developers to decide for themselves. Personally I'd use a lighter setting in development for better compiled output and errors, especially in code heavy with async/await or generators. But I’m the kind of person to test features with production settings before merging. It’s not safe if you don’t do this kind of testing so I’d make them match by default and document it somewhere that it is possible to loosen it up if you know what you’re doing.

[nelix]

It would be nice if this config also loaded required core-js poly and ideally inlined them via babel-runtime

[gaearon]

It would be nice if this config also loaded required core-js poly and ideally inlined them via babel-runtime

👍 Yeah, that's the plan.

[ai]

@gaearon browserslist master got env and package.json support. @hzoo do you need node queries in package.json on this step? Or we could release new Browserslist?

[ai]

Browserslist 1.5 was released with production/development and package.json support.

@hzoo I really need your feedback. Please do not ignore my messages :).

[ai]

Autoprefixer 6.6 is out with package.json support https://github.com/postcss/autoprefixer/releases/tag/6.6.0

[wtgtybhertgeghgtwtg]

I think this was fixed in babel@6.22.0.

[zikaari]

Thoughts on this -> https://philipwalton.com/articles/deploying-es2015-code-in-production-today/

cc @gaearon @Timer