Thanks whoever posted this article!!! On behalf of the webpack core team, we thank everyone who's been using webpack 2 since beta, we are at the finish line for getting final release. :) stay tuned
My favorite change is how configuration has been clarified. For example, see how loaders are configured now - instead of using a giant string delimited by special characters like this:
After having used both Webpack 1 and 2, my favorite feature is simply most of the insanity being gone.
I was hitting my head against my desk setting up npm and webpack 1 for almost 3 hours a couple of weeks ago. I then said fuck it, replaced them with yarn and webpack 2 respectively and all my issues were fixed.
I tried Webpack 2, and it still seems relatively insane to me. After switching over to Rollup my life has gotten a lot easier. It isn't quite as feature packed, but I'm glad to be done with importing a .css file in my .js file then having to specify a plugin to pull it back out again.
I still wonder how come the first syntax was considered a good idea in the first place ?
Figuring how to configure webpack 1 (haven't tried 2) is crazy, and I don't understand how people able to construct such a complex tool that is currently unique on the market, and works so well, managed to design a conf settings that badly.
Ironically the biggest challenge is involved with connecting a very declarative under the hood plugin architecture, to a more imperitive fluid configuration for users. We would love all the great ideas we can get!
System.import split-points for code splitting, generates bundles with dependencies for lazy loading by route (automatically code split react router routes). Should make progressive web apps and optimization easier.
The problem with tree-shaking is that it's recursive -- every module has to do it properly, and at the moment, I'd wager most frontend modules in NPM don't.
If I responsibly say `import { map } from 'lodash'`;, but (say) my frontend rendering library says `import _ from 'lodash'; _.map(things, func);`, then unfortunately, transitively, I'll still get all of lodash.
You might be able to fix that with something like babel-plugin-lodash which can be ran over your code (and deps) to enforce cherry-picking across the board.
Strange, I have it working with rc3.
I have an ES6 module exporting tons of Array utils. I definitely see the build size fluctuate depending on whether I import 1, 2, etc of these util functions, whether with webpack 1 (or most bundling tool apart from rollup) I would pay the entire file's price upfront.
not really looking forward to the release of webpack2, all it means is wrestling with existing webpack 1 configs (which are already fragile and difficult to deal with) to port them over.