Repository navigation
Consider using Webpack 2 #183
Description
Activity
I'd love to do this, we ported
react-boilerplateover a few months and have had 0 issues. If nobody else gets to it first I'll do it!Reacted by Josmar Dias and Iddan AaronsohnI did it for react-boilerplate, so, it's time for create-react-app!
Reacted by Max Stoiber, razh, nickcox, Stepan Kuzmin, Dmitrii 'Mamut' Dimandt, Tyler Whipple, Riccardo Gueli Alletti and Josmar Diashah, I was just working on this (before finding this issue). @7rulnik there's a branch here you can cop from if you find it useful: https://github.com/ChristopherBiscardi/create-react-app/tree/webpack-2
Reacted by Max Stoiber, Valentin Semirulnik, Sean Lynch, Yangshun Tay, Tyler Whipple, Chidozie Ijeomah, tuna and Augusto SandimI don't think this is as good of an idea as it might seem at first:
- webpack 2 may be stable enough for general use, but it's still marked as a beta, and thus not bound by semver guarantees, so there's no promise of stability from versioning
- For users who eject, it's going to be very difficult to find documentation on using webpack 2 – specifically, almost all docs out there are going to still be for webpack 1, and it's confusing as heck
- Just turning on webpack 2 doesn't give you the benefits of tree-shaking the way you think
- By default, webpack 2 doesn't look at
jsnext:main, so packages exposing ES module builds for rollup don't get their ES module builds used (in fact I'm not sure if any ES module builds from packages will get used in a default webpack 2 config)- Even if you add it, it turns out that a ton of package maintainers just stick their untranspiled source in
jsnext:main, which is actually just broken/wrong/won't work
- Even if you add it, it turns out that a ton of package maintainers just stick their untranspiled source in
- For most packages, tree-shaking yields limited benefit because of the limitations of static analysis; e.g. in React Router, it will not prevent pulling in the random singleton histories because it can't be statically determined that their instantiation doesn't have side effects... likewise for React-Bootstrap because of the HoC patterns used there (though once I realized the ES module build for React Router was pointless, I didn't go through with adding one to R-B anyway)
- (Apparently eslint-plugin-lodash fixes this though? – but does so by rewriting imports? cc @jdalton)
- By default, webpack 2 doesn't look at
So essentially, webpack 1 is tried and tested and relatively easy to find documentation on. webpack 2 seems pretty stable, but it's harder to learn right now, and the path forward to tree-shaking is fraught and yields not terribly many benefits.
Reacted by Daniel Lo Nigro, Dmitrii 'Mamut' Dimandt, chencheng (云谦), Vlad Shcherbin, JC, Albert Still, Constantine Antonakos and Paul Alexander(Apparently eslint-plugin-lodash fixes this though? – but does so by rewriting imports? cc @jdalton)
Do you mean babel-plugin-lodash or lodash-webpack-plugin?
babel-plugin-lodash, sorry.
(This package inspired me to muck around with my build tooling, and I got confused.)
Ah cool.
babel-plugin-lodashworks for non-lodash packages too. You just specify an "id" in its plugin options to be that of your package or as an array of package ids you want it to work for."plugins": [ ["lodash", { "id": ["async", "lodash-bound", "ramda"] }] ]
That's super cool.
To be concrete, even if you point at the React Router ES6 build in the current v3 pre-release in webpack 2, if you just do:
import { Router } from 'react-router/es6'; // Or use jsnext:main.
You will end up pulling in a bunch of code that you don't use, including stuff for e.g. the hash history, all the link and route helper components, &c.
In practice, tree-shaking is not enough to let you change the way you write imports, unless you use babel-plugin-lodash or something similar.
For a number of popular libraries, users should not rely on tree-shaking as built into the bundlers, and must find some other way to import just what they need, if they want a properly size-optimized bundle.
This means that, from my perspective, tree-shaking support also always has to come with a warning that goes along the lines of "don't rely on this – you still need to do deep imports in most cases".
There still is a benefit to using bundlers with native ES module support, but that benefit is restricted to getting rid of the Babel transpilation cruft.
Even if you add it, it turns out that a ton of package maintainers just stick their untranspiled source in jsnext:main, which is actually just broken/wrong/won't work
FWIW we have that enabled for
react-boilerplate, we have a lot of dependencies and only one of the broke but was fixed within hours. I'm fine with not adding that for now since I agree that the ecosystem might not be stable enough.almost all docs out there are going to still be for webpack 1, and it's confusing as heck
That's true, but the differences are tiny AND webpack warns you when you have something wrongly configured in the 1.x way. I do agree this might become a problem, though I know there's a lot of effort happening to make the webpack docs much better.
(Also,
resolve.packageMainsis nowresolve.mainFields: https://github.com/webpack/docs/wiki/Configuration#resolvepackagemains)I immediately hit breakage when I cut over my webpack config to webpack 2 earlier today.
I think that's there's a pretty significant cost to impose potential breakage on inexperienced users with packages that should work, especially when the reasons for that breakage are going to be very hard for a user who doesn't know what they're doing in track down (i.e. syntax errors in
node_modules).Okay, what?
The default supported ES module entry point hook in webpack 2 is actually
'module', per https://github.com/dherman/defense-of-dot-js/blob/master/proposal.md, from discussion in webpack/webpack#1979.The Rollup resolver plugin, on the other hand, doesn't know about
'module'and only knows about'jsnext:main'.What the heck are library developers supposed to do? Clutter up
package.jsonfiles with both? @gaearon are you planning on populating themodulekey in the Redux package definition?Reacted by Arian Valdez and Dmitrii 'Mamut' Dimandt7 remaining items
Just commenting in here that webpack 2 rc has released.
Reacted by Matt O'Keefe, Fernando Alex Helwanger, okbel, Marco Fugaro, Mike (Mykyta) Shulipa, Rossen K, Kirk Austin and Peter DiazReacted by Thaer Abbas, Fernando Alex Helwanger, okbel, Kent C. Dodds, Marco Fugaro, Mike (Mykyta) Shulipa, Rossen K, Sk Imtiaz Ahmed and Wiktor CzajkowskiLooks like webpack 2 officially hit final status!
Reacted by Jason Rhodes, Aaron Harris, Sk Imtiaz Ahmed, Marc Löhe, Jason Axelson and Peter DiazReacted by Jason AxelsonLooks like a great time to revive this. I've been working through the upgrade myself. Once it's ready, I'll submit a PR if no one else has.
Reacted by Jason Rhodes and dicekLooks like they have a PR going on over at #1291
When this will be published on npm?
UPD: oh, I see it is in milestone 1.0.0.
For future googlers: to use it right now
yarn add react-scripts@canary. To check available versionnpm view react-scripts dist-tagsAs always found answer in @gaearon tweet
@johann_sonntag @timer150 You can check the "milestone" field on any PR to learn which release it is slated for
— Dan Abramov (@dan_abramov) February 26, 2017When this will be published on npm?
When 0.10 is ready. (I’ll be looking at it this week.)
For future googlers: to use it right now yarn add react-scripts@canary.
No, please don’t do this unless you really know what you’re doing. There is a reason canary releases aren’t released as stable: they are buggy and not supported. It’s fine to try them but you should expect things to break.
Reacted by Max Stoiber, Rossen K and PatLovely to hear this is getting attention! Thanks for your efforts.
keep up with time!
- locked and limited conversation to collaborators
on Jan 21, 2019
It’s under active development, and from what I’ve heard, most bugs have shaken out by now. I’d like to see a PR porting this project to Webpack 2 so that we may compare them, and either to switch to it, or file issues against it 😄 . I’d expect such PR to use Webpack 2’s native support for ES Modules.
If you plan to work on this, please don’t forget to comment here so we don’t have duplicate PRs.