Live data from Hacker News

Webpack 2, RC 7

github.com

21–28 of 28 posts

Re: Webpack 2, RC 7

#22
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.

I wonder if the performance has improved.

Re: Webpack 2, RC 7

#23
post #4

Earlier quoted context omitted.

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 sp…

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.

Re: Webpack 2, RC 7

#26
post #13
post #9

Earlier quoted context omitted.

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

Re: Webpack 2, RC 7

#27
post #20
post #6

Earlier quoted context omitted.

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

Re: Webpack 2, RC 7

#28
post #27
post #20

Earlier quoted context omitted.

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.
Post reply on HN