-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revisit targeting ES6+ #2108
Comments
I think this is an interesting strategy: 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. |
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. |
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) |
note that webpack-contrib/uglifyjs-webpack-plugin#32 has been resolved in beta state. |
@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. |
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? |
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 |
@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. |
Also here, from the ipfs guys: ipfs-inactive/js-ipfs-http-client#611 (comment)
|
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 // 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. |
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! |
Would love this feature. Specifically for use in monorepos with symlinks for the local packages in ES6 |
For future reference, there are three unrelated issues here:
They’re all parts of the puzzle. |
I'll close this as too broad scope, we have a curated set of issues tracking this now. |
FYI, we're starting the work to compile deps with Let us know if you have feedback about how this should work. |
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.
The text was updated successfully, but these errors were encountered: