Revisit targeting ES6+

[gaearon]

https://www.npmjs.com/package/uglify-es is now on npm.

AFAIK both Autoprefixer and babel-preset-env support browserslist in package.json now, and uglify-es unlocks targeting ES2015 (for apps that don't care about older browsers).

We should investigate integrating those in a cohesive way.

[kasperpeulen]

I think this is an interesting strategy:
https://medium.com/dev-channel/es6-modules-in-chrome-canary-m60-ba588dfb8ab7

Basically, it recommends shipping two kind of bundles, an ES6 bundle, that will be picked by modern browsers using the type="module" attribute on the script tag, and for older browsers an ES5 bundle, with a nomodule attribute tag.

[ro-savage]

I did a test run of dropping support for IE using uglify-es and babel-preset-env with create-react-app, running a production app with bundle size of 292K.

I found it made almost no difference to file size or execution speed. (I was hoping to get file size down).

The big issue with filesize and bundle complexity is still the importing/bundling + the NPM modules being imported being pre-complied to ES5.

Still seems worth doing just didn't have nearly the improvement I was hoping for, so removed it to minimise differences with CRA.

If I get time I'll try and submit a PR for browser targeting this week. No guarantees though.

[ro-savage]

Changes can't be made until uglifyjs-webpack-plugin is updated to UglifyJS 3.x (Tracking issue webpack-contrib/uglifyjs-webpack-plugin#32) and then webpack is updated to include the new version.

(Unless we want to do something hacky)

[transitive-bullshit]

note that webpack-contrib/uglifyjs-webpack-plugin#32 has been resolved in beta state.

[tbillington]

@ro-savage Do you know of any efforts to distribute ES6+ builds of libraries alongside ES5 builds? I was hoping something would come along with the module syntax but haven't seen anything. As you said ES6+ builds will have negligible improvements until then.

[ro-savage]

As far as I am aware, there are no major libs targeting 'modern browsers'. Until IE10/11 disappear off the radar, most libs will by default support ES5.

In terms of having ES5 and ES6 builds of the same libs. Again, I haven't seen anyone really doing it but it is a decent idea. If you convince one major lib to start doing it, then stats would become available for others to know if its worth doing.

@gaearon - What about React 16 having two libs on npm. React and React-Modern that drops support for IE?

[cristiano-belloni]

That would be cool. I don't know of any major libs targeting "modern browsers", but there are some cool new libraries distributing their code in ES6 because they only target advanced browser functionality. Not being able to create a prod build with create-react-app because they're ES6 is a bit of a showstopper. Subscribing to this issue.

[wayneashleyberry]

@ro-savage I've actually run into this a few times, there are definitely packages and authors that don't bother transpiling their code any more. At the same time, authoring many packages within private organisations... not having to add pre-publish steps would be so nice.

sindresorhus/ama#446 (comment)

[cristiano-belloni]

Also here, from the ipfs guys: ipfs-inactive/js-ipfs-http-client#611 (comment)

What I would like to see is create-react-app to upgrade to the latest uglifyJS. Asking the entire world to publish ES5 code -- https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#npm-run-build-fails-to-minify -- specially when pretty much the only thing we do is Arrow Functions. Let me enphasize that there is an update uglifyJS that does indeed support ES6

[jozanza]

I'm 100% on the same page as that guy. The Arrow Functions thing in particular is incredibly inconvenient.

My current workaround is just patching react-scripts by injecting my own production webpack config before builds (no UglifyJSPlugin). And after build, I post-process the build js with uglify-es:

// in package.json "scripts" section
"prebuild": "cp webpack.config.prod.js node_modules/react-scripts/config",
"postbuild": "npx uglify-es build/static/js/main.*.js -c -m -o build/static/js/$(ls build/static/js | head -n 1)",

Super gross, but I'd rather do that than eject.

[wayneashleyberry]

Looks like create-react-native-app is using uglify-es by default, it'd be so nice to have parity in this project as well!

https://github.com/facebook/metro-bundler/blob/37995e2196d1de8bfc2db2442a0cdfbb8ef70999/packages/metro-bundler/src/JSTransformer/worker/minify.js#L15

[bogdansoare]

Would love this feature. Specifically for use in monorepos with symlinks for the local packages in ES6

[gaearon]

For future reference, there are three unrelated issues here:

• We want to switch to uglify-es so we don't crash on ES6 in deps.
• Still, this means uncompiled deps will break older browsers. To avoid this, we might support configuring target browsers (Make target browsers configurable #892) and then use that information together with engines from third-party packages to decide which modules to compile with babel-preset-env (Enable babel-preset-env for node_modules that target newer Node versions #1125). However it's not safe to precompile everything with Babel 6 (which forces strict mode) so we might need to wait for Babel 7 (Switch to Babel 7 #3522).
• For monorepos we might just want to support Yarn Workspaces and/or Lerna. (Support Lerna and/or Yarn Workspaces #1333)

They’re all parts of the puzzle.

[Timer]

I'll close this as too broad scope, we have a curated set of issues tracking this now.

[gaearon]

FYI, we're starting the work to compile deps with babel-preset-env in Create React App: #3776

Let us know if you have feedback about how this should work.