Repository navigation
State of targeting browers #3774
Description
I think we've all agreed targeting browsers would be an acceptable configuration. For 2.0, we tried giving this a shot -- here's the current state:
Parsing target browsers (#3644)
This change told our build pipeline to start looking for browserslist configuration.
When this was merged, the only real effect it had was CSS prefixing. It was not a complete implementation.
Our Babel configuration was still locked down to ES5.
Concerns
- Speed: what effect does this have on build time? Previously, we fed the configuration that now needs to be found (potentially found thousands of times depending on the build pipeline plugin efficiency)
- Configuration hell: We wanted to support
browserslistinpackage.json, but we now support 5 means of configuration. I think we need to lock this down. - What happens when nothing is specified? I'm not sure if we align with the
browserslistdefault.
Minifying code ES6+
We know we want to support the latest syntax, so we merged #3618 -- this PR switched us from uglify-js to uglify-es under the hood, which supports new syntax.
Concerns
- This now lets
node_moduleswith bad syntax leak into the build without being checked. - Specify JavaScript version for Uglify #3743 tried to solve this but upon further digging, the option is used twice in
uglify-esand does not actually limit syntax support in any way.
Outputting ES6+ code
Since #3644 didn't affect our compilation process, #3770 was merged.
#3770 removes our forced IE9/Uglify compatibility and instead lets @babel/preset-env use its new behavior of identifiying browser support via browserslist.
Concerns are shared with above:
- Speed -- what kind of performance hits are we going to see?
- Configuration hell (see above).
node_modulevalidity- Defaults when nothing is specified?
Compiling node_modules
Yet to be solved.
Concerns
- Not all packages specify an
enginesfield
Activity
Timer commentedon Jan 13, 2018
Potential solutions
Solving speed, configuration hell, and defaults
What if pre-eject we loaded and identified the targeted browsers ourselves?
We could make a helper in
react-dev-utilsand forward detected browsers to our Babel preset and Autoprefixer.This would fix any speed concerns and allow us to enforce a default other than what browserslist determines (we want our default to be
ie 11).Solving
node_modulessyntax validityThree options, currently:
We could do nothing and let the ecosystem catch up -- this is dependent on compiling
node_modules(via our engines idea).We could also petition
uglify-esactually limits language features based onecmaspecification.Alternatively, we could drop
uglify-esand switch tobabel-minify.babel-minifywould allow us to use the syntax support enabled bypreset-env/browserslistand ensure no code leaks through.This means every module needs to be parsed by Babel -- we could fix speed concerns here with accurate caching.
gaearon commentedon Jan 13, 2018
Can you clarify this? I’d assume it’s only queried once during startup. (Okay, twice: by autoprefixer and babel-preset-env.) Is that not the case?
I think it’s not too bad if we add a post-build message to production build with the chosen browserlist when it differs from the one in
package.json. It could include a link to browserslist docs.Do you only mean browserlist location? I would expect speed to be no worse since run the same number of transforms or less. (Speaking for the app code only.)
We could also go the other way and compile everything by default, skipping things that we know to be compatible. Maybe with caching it won’t be too bad?
Timer commentedon Jan 13, 2018
Fueled by this issue: webpack-contrib/eslint-loader#206. I just want to make sure
preset-envandautoprefixerdon't do something similar (I'm not saying they do, we should just check).I'm OK with this.
Yes, strictly browserslist location.
Are we confident babel 7 will no longer break code? If so, this might be fine -- but I'd almost rather make compilation opt-in via
enginesrather than opt-out to we can force the ecosystem to move forward.edit: then again, there's not really a good way to let users specify browser support -- just Node support. We need to talk more about this.
Timer commentedon Jan 13, 2018
Merging into #3777, we hashed this out.
andriijas commentedon Jan 16, 2018
@Timer thanks for all the efforts you are putting into browser targeting!