
Webpack 3: Official Release - daviddumon
https://medium.com/webpack/webpack-3-official-release-15fd2dd8f07b
======
cytzol
My favourite part of the Webpack 1->2 transition was when they updated their
old documentation to say that Webpack 1 was deprecated [0], but failed to
mention if the user was currently looking at the Webpack 1 docs or the Webpack
2 docs!

I ended up reading the Webpack 1 documentation for several weeks after 2 came
out. I'd see the warning, go "oh, I better not use Webpack 1 then", and
continue reading its docs. Cue lots and lots of head scratching.

Webpack developers: if you're going to release a new set of documentation for
3, then please, please make this clear.

[0]: For example, [https://webpack.github.io/docs/code-
splitting.html](https://webpack.github.io/docs/code-splitting.html). "webpack
v1 is deprecated. We encourage all developers to upgrade to webpack 2."
There's a link, sure, but I didn't follow it because I had no reason to think
I wasn't already on the Webpack 2 docs page. _grumble grumble_

~~~
simon83
When I google for "webpack someproblem" then the the first results are usually
pointing to the webpack 1 docs. I often don't even find documentation for
webpack 2 on the first page, unless I explicitly search for "webpack 2". It
took me some time, but now I'm always appending the version number to all my
searches. I think Angular has/had the same problem.

Edit: and luckily it's easy to discern the webpack docs: v1 docs look ugly and
are lacking information, v2 docs look much nicer and are more detailed ;) They
did a great job so far improving the documentation.

------
finchisko
I'm kind of surprised how cold reactions are against Webpack here on HN. I
consider Webpack by far the best module bundler. My path was: scripts,
stealjs, requirejs, requirejs + grunt and also recently tried SystemJS. All of
them are pretty awful. Try one of those and you'll realize how amazing Webpack
is. For example one of the newer bundler - SystemJS pretty much force you to
use jspm package manager. Jspm changes SystemJS configuration on every new
package installation, so you can be never sure, if build is failing because
jspm changed something. You can forget on imports without providing correct
extensions (js,jsx,...), or prepare to fill you config will lot of
defaultJSExtensions/file mapping. Also import Module from './module where
module is folder with index.js file doesn't work out of the box and mapping
has to be added. etc... The only thing I'm personally missing in webpack, is
option to provide custom chunk loader, so I can load chunks with any other AMD
loader, something similar to requirejs+almodjs or SystemJS static SFX builds,
which was the reason I've tried SystemJS at first place, but it wasn't worth
the pain.

~~~
yunyu
Have you tried rollup? Webpack's tree shaking is broken and doesn't work
properly with libraries structured like d3, while rollup's works properly.
I've managed to get trivial 150kb minified size reductions by switching.

~~~
Ralfp
But isn't Rollup.js directed at libraries whereas Webpack aims for JS apps?

~~~
moron4hire
I use Rollup for both, though I don't remember exactly how, as I made a
project out of my build setup: [https://capnmidnight.github.io/marigold-
build](https://capnmidnight.github.io/marigold-build)

------
elmigranto
Every time I start a new project, I try using latest webpack first. Result is
always me getting frustrated and replacing it with simple `browserify` call
with couple of `--transform` flags.

Recently I tried bootstrapping it with `create-react-app` and ejecting, so I
can modify webpack config. `yarn start` kept linting something deep inside
`node_modules`, and failing for some nefarious reason even after linting step
was removed completely from everywhere I could reach. `build` command work
fine, though, so go figure.

Not sure if "magic comments" will solve my problem, but it surely is nice to
have simple alternative, thanks substack and everyone behind browserify!
[https://github.com/substack/node-
browserify](https://github.com/substack/node-browserify)

~~~
manigandham
webpack is just more complicated, which means it takes longer to start - it
also has some bad naming and quirks which happens when design-by-committee
decisions take place.

the webpack book by survivejs takes a few hours to read completely, or an hour
to read the important parts, and you'll be very comfortable with it.

[https://leanpub.com/survivejs-webpack](https://leanpub.com/survivejs-webpack)
or
[https://survivejs.com/webpack/preface/](https://survivejs.com/webpack/preface/)

~~~
bicubic
> the webpack book

Holy shit, I thought you were kidding.

We're at a point where the bundler, one of a dozen elements required for a
'barebones' modern js application, needs a _book_.

I'm finding it hard to find motivation to do any kind of web based side
projects these days because they inevitably begin with 'which combination of
latest and greatest libraries do I need to spend an entire day wiring up
before I can do hello world this time?'. Someone make this madness end.

Modern javascript tooling makes 90s C++ look pretty pleasant.

~~~
manigandham
You can write a book about anything and it's also a great way to learn so not
sure why that is an issue.

webpack does a lot so it requires lots of knowledge -- or you could just stick
to script tags and basic minifiers built into every server side web framework
at this point.

npm (or yarn) for downloading dependencies + webpack to squeeze them into a
bundle makes for a very powerful combination _if you need it_ and it takes a
few mins at most to setup. Why the hyperbole if you don't understand it?

~~~
bicubic
> takes a few mins at most to setup

Now there's hyperbole.

Let's be honest. Unless you do it for a living, at best it takes a few hours
to set up boilerplate for any modern js project today.

And let's also be honest that es6 is a must today and script tags are not an
option until browser es6 support is ubiquitous.

Last project I set up, grunt and browserify were _the thing_. You were an
idiot if you weren't using them. Apparently now it's webpack and gulp. In
another year it'll be some other crap. The first step to dealing with a
problem is admitting there is one. I'm not sure labeling comments that
highlight the problem 'hyperbole' is constructive in any way.

~~~
bigleagueposter
Can't you just use a project starter script and get it set up in minutes?

~~~
bicubic
Which one?

The one with webpack? 1? 2? Now 3?

What about react? And redux. And react HMR. Oh and you probably need
immutable.js if you want to use react the 'proper' way not like those fools
last year. Your starter script was configured with react-router? That's a
shame, because it's no longer the latest and greatest, and everyone knows you
should have moved on to React Mini Router. Or is it React Universal Router
now? Wait is the particular configuration of webpack in this starter script
even compatible with the latest and greatest babel-loader? Hang on, you wanted
to use promises? Yeah, that's another plugin for polyfill and more config that
interacts with most of the above. Don't worry though, there's plenty of
tutorials to get it working with webpack... Oh wait, they're all for webpack
v1 and you're on v2.

~~~
aaron-lebo
So don't upgrade to the latest and greatest tech? Find something that works
and use it just like anything else.

Is your complaint really that there's new tech out and you have the option to
use it? Do you complain every time a new language releases? Do you use Django
1.2 because you don't feel like upgrading to 1.3, 1.5, 1.8?

I don't exaggerate in saying that the comments you've posted in this thread
have taken more time than it would take to have a basic webpack setup.

------
skrebbel
In semver land, every major release is a tragedy. I love that they're really
doing hard (and free!) work to make the transition as smooth as possible, but
I still wish the JS ecosystem culture would be more conservative about
releasing breaking changes.

~~~
coffeedoughnuts
From the article:

Migrating from webpack 2 to 3, should involve no effort beyond running the
upgrade commands in your terminal. We marked this as a Major change because of
internal breaking changes that could affect some plugins. So far we’ve seen
98% of users upgrade with no breaking functionality at all

~~~
skrebbel
Your point being? The plugin interface is a public interface too, right?

Again, I really appreciate all the work done to make this smooth, but there's
still a little underlying "compatibility matters less than features" sentiment
here.

~~~
nilliams
> The plugin interface is a public interface too, right?

It didn't say 'plugin interface'. It said 'internal changes' that could affect
some plugins. The way I read that is some plugins could be relying on
internals (that they technically shouldn't, they may have good reason ofc).

------
GlennS
Having gone through script tags -> Browserify -> Webpack, I now have the
sneaking suspicion that Google's Closure compiler was the right thing all
along, and that I should have learned that to begin with.

------
daliwali
I used both and still prefer Browserify. No configuration required, it just
does what you want. Also its source code is quite short and easy to grok.

------
hoodoof
Thanks to the Webpack people for focusing on ease of use, ease of migration
and avoiding breaking changes.

react-router has recent gone from version 3 to version 4, which is essentially
a completely new and almost unrelated piece of software to V3 and requires a
major rearchitecture of your application to make the transition. In effect it
is one big breaking change.

~~~
aocvr
Upgrading from 3 to 4 is not required. Version 3 is still maintained. It's not
ideal since there will probably be no future major 3 versions, but no one is
forced to make a 'big breaking change' strictly speaking.

> We intend to keep supporting the 3.x branch indefinitely (published
> separately on npm to aid in migration), although there will likely not be
> any future major versions based on that code. 4.0 is the future, but we
> won't leave you hanging if you want to stick with 2.x/3.x.

[https://github.com/ReactTraining/react-
router/releases/tag/v...](https://github.com/ReactTraining/react-
router/releases/tag/v4.0.0-0)

Previously discussed here:
[https://news.ycombinator.com/item?id=12511419](https://news.ycombinator.com/item?id=12511419)

~~~
tchow
4.0 is a regression imo. The docs say that if you do server side rendering
with code splitting then 'God Speed' (their words not mine).

I don't see the benefit of switching if v3 allowed me to ssr and code split
while v4 doesn't allow me to do both.

From the user pov it went from instantly displayed page with minimal js
required to choosing one of those options.

What benefits could exist that supercede giving the user the best possible
experience? (Genuine question).

I can't imagine huge speed gains going from one page to the next from this
change and indeed changing pages in SPAs are essentially instant. So what
could possibly be better that makes it worth getting rid of ssr and code
splitting? Imo I won't be using react-router in future products because they
are too fickle with their codebase.

~~~
jazoom
This was the madness that finally pushed me over the edge and towards Vue
about 8 months ago. No regrets here!

------
kakarot
Nice, I noticed the push earlier tonight on github and tried upgrading to 3.0
in the project I was working on, but I guess it was a little too soon and I
ran into dependency errors.

Here's to hoping that we see a performance _increase_ instead of a performance
_decrease_ as was the case with 2.0.

