Hacker News Reader

Comment by lugg | Hacker News Reader

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/

View on HN

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.

Reply on news.ycombinator.com