My favourite part of the Webpack 1->2 transition was when they updated their old documentation to say that Webpack 1 was deprecated [0], but failed to mention if the user was currently looking at the Webpack 1 docs or the Webpack 2 docs!<p>I ended up reading the Webpack 1 documentation for several weeks after 2 came out. I'd see the warning, go "oh, I better not use Webpack 1 then", and continue reading its docs. Cue lots and lots of head scratching.<p>Webpack developers: if you're going to release a new set of documentation for 3, then please, please make this clear.<p>[0]: For example, <a href="https://webpack.github.io/docs/code-splitting.html" rel="nofollow">https://webpack.github.io/docs/code-splitting.html</a>. "webpack v1 is deprecated. We encourage all developers to upgrade to webpack 2." There's a link, sure, but I didn't follow it because I had no reason to think I wasn't already on the Webpack 2 docs page. <i>grumble grumble</i>
I'm kind of surprised how cold reactions are against Webpack here on HN. I consider Webpack by far the best module bundler. My path was: scripts, stealjs, requirejs, requirejs + grunt and also recently tried SystemJS. All of them are pretty awful. Try one of those and you'll realize how amazing Webpack is. For example one of the newer bundler - SystemJS pretty much force you to use jspm package manager. Jspm changes SystemJS configuration on every new package installation, so you can be never sure, if build is failing because jspm changed something. You can forget on imports without providing correct extensions (js,jsx,...), or prepare to fill you config will lot of defaultJSExtensions/file mapping. Also import Module from './module where module is folder with index.js file doesn't work out of the box and mapping has to be added. etc... The only thing I'm personally missing in webpack, is option to provide custom chunk loader, so I can load chunks with any other AMD loader, something similar to requirejs+almodjs or SystemJS static SFX builds, which was the reason I've tried SystemJS at first place, but it wasn't worth the pain.
Every time I start a new project, I try using latest webpack first. Result is always me getting frustrated and replacing it with simple `browserify` call with couple of `--transform` flags.<p>Recently I tried bootstrapping it with `create-react-app` and ejecting, so I can modify webpack config. `yarn start` kept linting something deep inside `node_modules`, and failing for some nefarious reason even after linting step was removed completely from everywhere I could reach. `build` command work fine, though, so go figure.<p>Not sure if "magic comments" will solve my problem, but it surely is nice to have simple alternative, thanks substack and everyone behind browserify! <a href="https://github.com/substack/node-browserify" rel="nofollow">https://github.com/substack/node-browserify</a>
In semver land, every major release is a tragedy. I love that they're really doing hard (and free!) work to make the transition as smooth as possible, but I still wish the JS ecosystem culture would be more conservative about releasing breaking changes.
Having gone through script tags -> Browserify -> Webpack, I now have the sneaking suspicion that Google's Closure compiler was the right thing all along, and that I should have learned that to begin with.
Thanks to the Webpack people for focusing on ease of use, ease of migration and avoiding breaking changes.<p>react-router has recent gone from version 3 to version 4, which is essentially a completely new and almost unrelated piece of software to V3 and requires a major rearchitecture of your application to make the transition. In effect it is one big breaking change.
Nice, I noticed the push earlier tonight on github and tried upgrading to 3.0 in the project I was working on, but I guess it was a little too soon and I ran into dependency errors.<p>Here's to hoping that we see a performance <i>increase</i> instead of a performance <i>decrease</i> as was the case with 2.0.