Consider using Webpack 2

[gaearon]

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.

[mxstbr]

I'd love to do this, we ported react-boilerplate over a few months and have had 0 issues. If nobody else gets to it first I'll do it!

[7rulnik]

I did it for react-boilerplate, so, it's time for create-react-app!

[ChristopherBiscardi]

hah, 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

[mxstbr]

Sorry, I was in the middle of it already when I read this! See #189, feel free to continue the work against the webpack-v2 branch.

[taion]

I 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
  • 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)

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.

[jdalton]

(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?

[taion]

babel-plugin-lodash, sorry.

(This package inspired me to muck around with my build tooling, and I got confused.)

[jdalton]

Ah cool. babel-plugin-lodash works 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"] }]
]

[taion]

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.

[mxstbr]

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.packageMains is now resolve.mainFields: https://github.com/webpack/docs/wiki/Configuration#resolvepackagemains)

[taion]

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).