Comment by exogen | Hacker News Reader

Comment by exogen | Hacker News Reader

Parent Full thread

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

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. :)

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.

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.

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

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.

Reply on news.ycombinator.com