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:

    'css-loader?modules-true!postcss-loader!sass-loader'

Loaders are configured with an ordered list:

    [
      {
        loader: 'css-loader',
        options: {
          modules: true
        }
      },
      {
        loader: 'postcss-loader'
      },
      {
        loader: 'sass-loader'
      }
    ]

It takes up way more space but it's also entirely clear what's happening.

More config changes are summarized here:

http://javascriptplayground.com/blog/2016/10/moving-to-webpa...

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.

Truly magical.

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.

> I still wonder how come the first syntax was considered a good idea in the first place ?

I think it came from RequireJS, probably intended for one-off usage (e.g. a single require that requires a certain loader)

Still a bad idea, though.

http://requirejs.org/docs/plugins.html (Jan 2011: https://web.archive.org/web/20110109084245/http://requirejs....)

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.

yes, best feature.

before you had to use systemjs and jspm or something.

or require.ensure()

Seems like the headline feature is tree-shaking to remove unused files.

Except in my experience (and others as well) the tree shaking hasn't been working.

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.

https://github.com/lodash/babel-plugin-lodash

Late reply, but, neat! I'll have a look.

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.

lots of refactoring/rewriting in/for ES6

https://gist.github.com/sokra/27b24881210b56bbaff7

DOCUMENTATION (no seriously...stuff is more documented than 1)