Webpack 4.0 | Hacker News Reader

Webpack 4.0

github.com

160 pointsbpierre28 comments

webpack team, great work on this! The new `sideEffects` option is the big one we've been waiting for – lots of bundles are going to be much smaller.

People like to gripe about webpack and JS bundlers in general. At my last company, before webpack and browserify had really caught on (and before a bunch of other bundlers even existed), I crafted us a custom JS build solution using Make. It had just the right amount of smarts (but was mostly a dumb concatenator and wrapper), and was extremely fast and simple. Basically, it was a cranky old HN poster's wet dream.

And you know what? It still fucking sucked. We had to vendor most of our dependencies and then manually edit their source code to modify references, because Make doesn't understand JS dependencies or module resolution. We couldn't expose or even check for globals like `require` or `define` because we were third-party JS living on other people's sites with their own JS, and any accidental intermingling could break their shit, or our shit.

webpack solves all of that. It is absolutely necessary and anyone who says otherwise doesn't understand the problem space. So cheers on another release!

Does sideEffects do what I suspect: prevents global scope modification, e.g. setting window.$ = jQuery ? And even jQuery itself I guess?

I'm not really up to speed on this side of things so I'd like to hear you and other view points on how webpack is shaping up against say brunch[1]? (which I'm kind of partial to)

[1] http://brunch.io/

Naw, it has to do with tree-shaking imports. webpack might have a different option for what you describe – if not, most linters certainly do.

`sideEffects` explicitly tells webpack whether it's safe to remove unused exports from a module, because it's always possible that code relies on them implicitly.

EDIT: I'm just going to link to the official docs (which don't mention `sideEffects` yet) because my last example was slightly wrong: https://webpack.js.org/guides/tree-shaking/#caveats

To work around the caveat mentioned in the docs above, the module author can include `sideEffects: false` in their package.json to notify webpack that excluding certain code is safe.

As an example, I just built a file that does:

    import { compose } from 'redux';
    console.log(compose);

`compose` is a really tiny no-dependency utility from Redux. The resulting bundle is 2.12 KiB. That's because webpack isn't sure whether all the other stuff exported from Redux causes any side-effects.

If I edit Redux's `package.json` to specify `sideEffects: false` and rebuild, the bundle size goes down to 799 bytes: only `compose` itself is included! There are pull requests happening all across the JS ecosystem to add this flag to popular dependencies.

See this issue for more details: https://github.com/webpack/webpack/issues/2867

That sounds awesome! Could anyone point me to some examples or docs on this new feature? I tried searching for `sideEffect` on https://webpack.js.org/ but came up empty.

So is it safe to just enable then... if not, what would one have to look for to ensure nothing gets messed up? And furthermore, if it 'always works', why didn't they just add it before?

It's not a global setting, but rather something individual module authors can enable in their `package.json` – or, if you're working with a module that hasn't specified it, you can tell webpack to treat that module differently via `rules`.

So if you're a library author and you know none of your modules contain side-effects, you can set `sideEffects: false` and anyone using webpack with your library will benefit. :)

It would be odd to me to describe webpack as "shaping up against" Brunch. Brunch is basically niche by comparison – by # of installs, webpack is roughly 172X more popular. webpack not only has more features, but I wouldn't expect Brunch to be much faster even before webpack 4. Just a guess though.

Aren't there other bundlers out there which are much faster, much smaller, and already have had tree shaking for quite a little while? Why are you stating that Webpack is necessary I must be one of the people who doesn't understand the problem space.

I didn't mean webpack specifically, rather that module bundlers themselves are a worthwhile pursuit.

I created a cranky old HN poster's wet dream: https://github.com/serprex/mkcjs (readme examples of use are now outdated, since they no longer use mkcjs)

Used it for openEtG until a few months ago, where switched from pixi.js to React, & switched to webpack. The 2 minute build time compared to basically-instant was a bit of a hassle, but now we support IE

> You have to choose (mode or --mode) between two modes now: production or development.

I think what we have here is the start of a new era for heisenbugs to thrive.

The reason I suspect so is because a lot of JavaScript packages are written in awkward ways that makes lots of assumptions about the packages loaded, the order of the load, monkey patching require, and a whole lot of other oddities.

With current setup, you can disable various plugins and optimizations to pin point the conditions under which a bug manifests.

With new release, now you have to figure out what is the current state of the configurations to begin-with and how changing modes impacts that.

If I understand correctly, using `mode` is optional. You can still continue using full configuration if required.

But I get your point. There might be problems if people start using it without understanding the internals.

> a lot of JavaScript packages are written in awkward ways that makes lots of assumptions about the packages loaded, the order of the load, monkey patching require, and a whole lot of other oddities

And therein lies the bigger problem. As long as this cancerous code style is tolerated, we'll be putting workarounds on top of other workarounds instead of making actual progress.

Great! Is there migration guide available from version 3.* ?

I’m psyched for sideEffects: false and better dead code elimination. So much more treeshaking!

Nice! Will be curious to see some benchmarks vs https://github.com/parcel-bundler/parcel

Do you have experience with using parcel in production? How is it? On a previous project, our webpack bundle could take up to 20+ seconds - but we love the customizability that comes with webpack.

Parcel is awesome and works well in production. More often that not, a lot of configuration is not needed. It's nice to be able to just "parcel index.html" instead of 2 hours of configuration :)

Here's one datapoint, from building the single JS entrypoint for this simple demo site: https://exogen.github.io/layup/

First build:

    Parcel:    23.9s, 422K output size
    webpack 4:  9.6s, 399K output size

Rebuild (cached, no changes):

    Parcel:     900ms
    webpack 4: 1400ms

And we haven't implemented persistent caching and multithreading yet ;) just getting faster and faster.

Maybe I'm the crazy one here, but giving plugin authors a single month to get updates out to support webpack 4 was a really irresponsible way of releasing this. When people kvetch about what a shitshow the javascript scene is, this is exactly the kind of thing they're talking about.

What are you even talking about? It's a semver-MAJOR release. Nobody is going to accidentally upgrade to 4 and have everything break, unless they are very confused and cavalier with bumping their dependencies. So people relying on old plugins can just stick with webpack 3 which works perfectly fine.

I'm not a webpack contributor, but I'd rather get a new version into everyone's hands sooner rather than wait for random third-party developers not associated with the project to get their stuff in order.

Its not a matter of whether someone accidentally upgrades to a major release. Its a matter of whether the release is ready to use in production, and when you have plugins like extract-text that are crucial components to the vast majority of workflows and they haven't been given enough time to upgrade, you can't seriously claim that v4 is production ready.

If its a matter of putting it in the hands of users sooner than later, that's what a beta period is for. Releasing this before the documentation is even ready is just irresponsible.

Anybody up for a competition? Basic 'app'.

You: Yarn, Bower, Babel, typescript, grunt, webpack 1, npm 5.7, webpack 2 & 3, Browserify, React, and... Gulp.

And Grunt.

Me: java EE.

This is called a strawman, you're suggesting people use 3 different versions of webpack and another bundler at the same time?

Real talk, this is the modern stack:

If you want to write a simple animation or calculation on a: Javascript. Nothing else.

You have several behaviors on your page and and to use modern code practices: Babel. That's it.

You want a complicated Web app with Rich functionality on several pages: React, Webpack, Babel. That's it.

Typescript can replace Babel, if you like strong typing.

Even that is probably overcomplicating it at this point. npm install —save-dev create-react-app. Done!

And _that_ is an overcomplication, as create-react-app pulls in far more dependencies than the aforementioned stack (and is actually the aforementioned stack wrapped up in a cli).

Your comparison isn't even remotely correct. In reality it's Webpack+NPM (plus a bunch of webpack plugins) vs Maven (and at least a comparable number of Maven plugins).

Reply on news.ycombinator.com