
Webpack 4.0 - bpierre
https://github.com/webpack/webpack/releases/tag/v4.0.0
======
exogen
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!

~~~
lugg
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/](http://brunch.io/)

~~~
exogen
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](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](https://github.com/webpack/webpack/issues/2867)

~~~
Exuma
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?

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

------
omeid2
> 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.

~~~
Garbage
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.

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

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

------
rattray
Nice! Will be curious to see some benchmarks vs [https://github.com/parcel-
bundler/parcel](https://github.com/parcel-bundler/parcel)

~~~
exogen
Here's one datapoint, from building the single JS entrypoint for this simple
demo site: [https://exogen.github.io/layup/](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

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

------
karmajunkie
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.

~~~
exogen
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.

~~~
karmajunkie
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.

------
hiram112
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.

~~~
coltonv
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.

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

~~~
filleduchaos
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).

