Make target browsers configurable

[gaearon]

Imagine package.json like this:

  "browsers": {
    "development": "last 1 version",
    "production": "last 2 versions, > 5%"
  }

The format is the same as browserslist.

Then, we would use this information both for Babel and Autoprefixer.

Autoprefixer already supports this format of browser configuration.

We could teach babel-preset-env to honor it too, or we could write a helper that translates browserslist to its target.

This would solve #435 with some optional configuration.

It would make rebuilds faster and also make output less mangled without introducing sourcemaps, helping work around #139.

[gaearon]

cc @hzoo

[hzoo]

👍 and FYI we have babel/babel-preset-env#19 in progress as an option already so that's a start 😄

[gaearon]

Omg that's so cool. Wow. I'm excited.

[hzoo]

I think I got the data layer correct (mostly) so it's just on all of us to make sure that the data in https://kangax.github.io/compat-table/es6/ is correct (please check + make PRs to change this) - example I updated the table for node in compat-table/compat-table#932

Good if we get a lot of testing/eyes through usage.

There might be some issues with not compiling some features while compilng others but we'll just have to find those and fix them

[AlicanC]

This is a step backwards for SSR and universal JS in general. Node is a very valid target for React applications and this proposal completely ignores that fact.

You (CRA and Babel) should strip the query parser from browserslist and query kangax instead of caniuse.

(Now I have to go and read the Yarn announcement.)

[gaearon]

Sorry, I don't quite understand your comment.

Node is a very valid target for React applications and this proposal completely ignores that fact.

This is "Create React App" repo. The project explicitly does not support server rendering, nor does it intend to. Why is this a "step back" when server rendering is not supported by it?

If CRA supported Node, we'd detect Node environment exactly the same way. In fact we already do for tests: #878. So I still don't see why this would pose a problem even for people who eject and want to add server rendering.

The "browsers" field would not somehow make this code executable only by the browsers 😉 . It just lets us infer target environments as a moving target instead of assuming ES5 as a base. And tools like -env preset are just as relevant for Node as they are for browsers. Luckily we don't need a separate field for Node because we can just check process.version as we do in #878.

Could you please explain more?

[AlicanC]

Oh, I'm sorry. I mistakenly thought CRA's view of SSR was changed from "no intent" to "some intent". Don't mind my comment then.

[hzoo]

Merged babel/babel-preset-env#19 and release 0.0.6 with "browsers" in the config

[ai]

Right now Browserslist already have a browserslist config.

It has no development/production versions and doesn’t support section in package.json.

We could add both features if it is really necessary :).

[gaearon]

@ai The separation between dev/prod is important to us but I'd be happy to just keep it as part of CRA itself. If you'd like, you could adopt it, but then you'd have to figure out a conventional way to determine which config should be chosen which is tricky. In case of CRA we know this unambiguously because we have separate commands for running app in dev and prod. Reading NODE_ENV might be too error-prone because people often forget to set it.

[ai]

It is hard to make it CRA-only but use in other user tools. Like when user add Stylelint, it will not share common config from package.json.

Why dev/prod is important? Maybe we could find better solution?

[gaearon]

It is hard to make it CRA-only but use in other user tools.

Isn't it possible to pass the desired list to browserlist function, and have it override any configs? Then we'd just read our package.json and pass that to it from CRA.

Why dev/prod is important? Maybe we could find better solution?

This would let people transpile less in development because they can specify they develop on modern browsers. Both Babel and Autoprefixer would do less work and produce cleaner output, but for production they'd do the more conservative transformations.

[gaearon]

OK, I think I get it now.

Like when user add Stylelint, it will not share common config from package.json.

Fair enough, but then this is the case now as well, where browserslist is not respected at all. At least it's a step in the right direction, wouldn't it be?

Maybe browserslist could support

{
  env1: list1,
  env2: list2
}

notation and accept environment as an argument.

If it is not specified, all rules are summed up (env1 + env2) to be more conservative. If specified, only the right environment is picked.