Looking at the list of changes (<a href="https://webpack.js.org/guides/migrating/" rel="nofollow">https://webpack.js.org/guides/migrating/</a>), it seems like a lot of "magic" has been removed.<p>That's good. It's kinda funny how this is a very frequent pattern: Build something full of magic and, as you grow more mature and hit pain points, end up removing the magic.<p>I've had a very similar experience in my career so far as a dev. My code used to be full of magic, auto-guessing things based on how methods are named, etc. I've moved away from that, it wastes more time than it saves.<p>Anyone else with the same experience?
Recently moved to this from webpack 1 for both personal projects and work. Webpack 2 combined with Yarn running inside of Docker to automate builds is the nicest (and fastest) frontend build pipeline I've had yet.<p>The experience with Webpack2 is so much better:<p><pre><code> - Cleaner documentation
- Saner configuration files:
- It errors out if you add incorrect flags!
- This means that postcss et. al. use config files
- Saner module definitions (now called rules):
- No query flags!
- Actual object support!
</code></pre>
Plus tree shaking, code splitting etc. It's way better. Now looking forward to integrating babili within webpack to remove uglify.<p>If you're thinking of upgrading it's not that much effort given the new documentation, too. Definitely worthwhile, and there seems to be less occasional build bugs using this with newer babel plugins (originally switched because of a crazy stackoverflow parsing a two-deep object).
This thing is so complicated and so full of magic and options and the documentation is so shallow, I can't find examples, can't get a tutorial that isn't uselessly superficial.<p>I've tried using Webpack in its begginings, because React people only talked in Webpack terms, but then switched back to Browserify, which is simple, not magical and straightforward. I tried using Webpack again lately, with the bizarre Gatsby static site generator, and the failures are enourmous. I can't even understand how exactly does a loader work. Gatsby makes forced use of something called webpack-config or something like that, which is just a useless abstraction on top of the already confusing Webpack config.<p>Please, someone explain to me what does this thing do that Browserify can't.
It is hard to find well maintained JS libraries in these days. Thanks a lot for the mature work done here, especially in terms of documentation. So many OS projects launch their new shiny versions in such a rush, they leave their users in darkness for a very long time.
One big question I have from Webpack is this:<p>In age of HTTP/2 packing is not recommended anymore but I love so many features of Webpack, are you guys going to adopt to HTTP/2 paradigms?<p>Great work, thanks!
webpack is great. HMR and code-splitting are killer features. Only thing that I'm worried about is tree shaking. There are a couple of long standing issues about problems with classes and export all statements. Rollup is missing code-spliting, webpack doesn't do tree shaking well and complains about bundle sizes. Not sure what to do. If somehow rollup could be integrated, that would be perfect.
Thank goodness I decided to bite the bullet last week and make the jump to v2. Upgrade took a while but was rather painless thanks to the great migration guide on the new documentation site.<p>If you are using a ton of loaders that aren't v2 ready you may have a more painful experience, you'll have to get familiar with the LoaderOptionsPlugin.<p>If you're newish to webpack it could be a frustrating experience.<p>Shout out to the webpack team though, It's an impressive tool.
Reading through the Webpack2 release tags I came across the v2.1.0-beta28 changelog, which mentions:<p>> * add `import()` as Code Splitting construct. It should be used instead of `System.import` when possible. `System.import` will be deprecated in webpack 2 release (removed in webpack 3) as it's behavior is incorrect according to the spec.<p>I was under the impression `System.import` would be the new way to do code splitting and hence supersede `require.ensure()`. After further checking, now it seems like the function-like `import()` will be used instead [1], which is better accepted in browsers than `System.import()`.<p>[0] <a href="https://github.com/webpack/webpack/releases/tag/v2.1.0-beta.28" rel="nofollow">https://github.com/webpack/webpack/releases/tag/v2.1.0-beta....</a>
[1] <a href="https://github.com/webpack/webpack/issues/3098" rel="nofollow">https://github.com/webpack/webpack/issues/3098</a>