
An attempt to upgrade to Webpack 4 - isuckatcoding
https://gist.github.com/gricard/e8057f7de1029f9036a990af95c62ba8
======
andrew_
Hello. Webpack team member here. The webpack@4 release was, well, interesting.
I can't add much that hasn't already been said - but I can say that we're
working to make sure there will never be another webpack release that suffers
from the same kind of documentation shortcomings. There's a metric poopton of
good stuff in the release, and we're still working to get all of it written
down. That said, look for future major releases to be far more proactive than
reactive with regard to documentation, announcements, and migration details.

~~~
tbrock
Hey thanks for all the hard work!

> _I can say that we 're working to make sure there will never be another
> webpack release that suffers from the same kind of documentation
> shortcoming_

We still have time to make sure this release has good docs. Please don’t give
up on it just yet!

Can we make some task issues on github that ask people to document a portion
of the code/process?

~~~
shakna
Have a look at this issue [0], I think it covers most of the docs for v4.

[0]
[https://github.com/webpack/webpack.js.org/issues/1861](https://github.com/webpack/webpack.js.org/issues/1861)

------
btown
IMO, Webpack (and React Router [0]) have been in this weird and honestly toxic
place, where there was very little regard held for backwards compatibility and
gradual deprecation by the core teams _at first_ , so businesses with larger
apps became marooned on previous versions as soon as the first major version
change... thereby not contributing their expertise and bug reports (they spent
that time fighting against the lack of documentation), and thereby making it
even more difficult for the core teams to get feedback on people's real-world
migration woes.

It's fair to say that there were problems in the earlier APIs, but if that's
the case, make changes gradually, even create an RFP process, tease/market
your API change proposals to get feedback from people who might say "this is
not something we can adopt easily, but you could add this param for backwards
compatibility." It'll take longer to get to an API that feels "perfect," but
it makes for a stronger culture.

[0] [https://github.com/ReactTraining/react-
router/blob/master/pa...](https://github.com/ReactTraining/react-
router/blob/master/packages/react-router/docs/guides/migrating.md)

~~~
bfred_it
I remember reading of Babel maintainers releasing betas and asking for
feedback but not many helped; most just came to complain after the release.

Webpack 4 has been in beta for a while but not enough people tested it on real
projects, evidently.

~~~
sho
> Webpack 4 has been in beta for a while

Perhaps the naming is sending the wrong message? "Beta" sounds incomplete and
subject to change; I certainly don't make a habit of introducing betas to
serious projects unless there's something in them I'm desperate for.

An extended period of Release Candidate versions could give end users more
confidence in adoption. This naming implies that the product is finalised and
will be released as-is barring serious bugs. It's a small thing, but maybe
giving end users the feeling of being early adopters rather than beta testers
could increase uptake in this final critical stage.

~~~
rdsubhas
Or React's way of avoiding major version cliffs seems to have grown out of
this problem.

[https://reactjs.org/blog/2016/02/19/new-versioning-
scheme.ht...](https://reactjs.org/blog/2016/02/19/new-versioning-scheme.html)
(skip to the major versions and avoiding cliffs part)

------
lmcardle
As someone who has worked with many of the various tools out there, I have a
lot of respect for the way the EmberJS team handles upgrades. I personally
wish more teams learned from their success. Their mantra is “stability without
stagnation.” While it is not perfect, the team appears to try hard to move the
framework forward without breaking backwards compatibility. When it comes to a
major release, I.e. the just released 3.0, the team released no new features,
but rather just removed the features that had been depreciated in earlier
releases.

Like or hate Ember as a framework, the team has developed some very good
release processes and practices a lot of us could learn from.

------
stevebmark
According to Webpack's donation site,
[https://opencollective.com/webpack](https://opencollective.com/webpack), the
creator of Webpack, "Sokra," made $44,164 off of Webpack development in 2017
(and $9,000 so far in 2018).

We're in a new world of sustainable open source software development, enabled
by services like Patreon and this one.

Maybe it's petty, but as someone who works on several open source projects
without reimbursement, I hope that such "hefty" funding leads to better
documentation, better community support, and cleaner upgrade paths. Webpack is
notoriously fickle and confusing when it comes to configuration, and at a
glance Webpack 4 doesn't seem to have helped with that. Although I certainly
appreciate performance improvements.

Can I request that funds be diverted into community support and enforcing
clean writing across documentation pages? That's what Webpack needs most, and
has always needed, by far over any core API changes.

~~~
sho
> the creator of Webpack, "Sokra," made $44,164 off of Webpack development in
> 2017

While I certainly welcome this new trend I wouldn't exactly call sub-45k
"hefty". That's far below what the author could presumably make working for
one of the big shops, and doesn't exactly leave much to "divert" if the author
has any plans to pay rent, buy food, etc.

As stated it's a great and promising trend, but I wouldn't be too hasty in
calling for the author to start redistributing a fairly minimal income. That's
barely enough for one person, let alone "staff".

------
ericmcer
Is it weird that I miss gulp and even grunt sometimes? Webpack does some
really cool stuff with basic configuration, but gives me a scary black box
feeling, like if it really wanted to it could stop working and I would be
unable to fix it. I never got the same feeling with gulp/grunt, maybe the
bulky config files give a sense of control.

~~~
unclebucknasty
> _gives me a scary black box feeling, like if it really wanted to it could
> stop working and I would be unable to fix it_

This was verbatim my thinking when evaluating Vue 2 a while back. Its reliance
on Webpack or Browserify for optimal use really gave me pause. I could just
see myself losing days trying to figure out which bit got flipped to stop its
working.

Vue 2 was new at the time as well, so I wasn't sure about adoption, ecosystem,
and/or the maintainers' committment. Looking back, I would've rolled the dice.
But, all of this to say glad I'm not alone in that black boxes give me pause
in a world where everyone seems to rush headlong into the next big thing,
ceding ever more control.

~~~
CharlesW
> _Its reliance on Webpack or Browserify for optimal use really gave me
> pause._

Mind elaborating on what you mean by "for optimal use"? For example, I use
Brunch with Vue 2 and it seems to work fine.

~~~
LukeShu
There is no complete stand-alone Vue SFC compiler; every SFC compiler is
written as a plugin for a specific bundler. The 3 official implementations are
the Webpack, Browserify, and Rollup plugins. There's no significant code-
sharing between them (and I'm _sure_ there are no subtle differences that will
bite you), and the Browserify and Rollup plugins can lag months behind the
Webpack one--they still don't support functional SFCs, which were added in Vue
2.5.0 back in October.

So, how does vue-brunch work? It declares the Browserify plugin as a
dependency, and wraps it.

~~~
unclebucknasty
Exactly this. And Rollup wasn't available (or at least well-publicized) when I
was evaluating about a year ago.

------
monaghanboy
Another major version was again released? Seems like literally just a few
months ago when, just after upgrading my team's codebase to Webpack 2, Webpack
3 came out.

Why do front-end application frameworks (e.g. Angular, and even React) and
build tools constantly feel the need to reinvent what they just reinvented?
Don't people (users and developers alike) recognize and tire of the churn?

Stepping back though, a thread like this appears on HN at least once every few
months, so I guess this is just par for the course.

~~~
franciscop
Because they learn from mistakes and can make it better the next time! That
happens everywhere; except JS world (at least with npm) is very, very new
(relatively speaking). Also now there are many more devs than when the _older_
languages came out, so the experimentation is a lot wider.

~~~
vanderZwan
> Because they learn from mistakes and can make it better the next time!

Well, except seemingly learning from the mistakes made when introducing
breaking changes.

I not being a cynical jerk bashing on WebPack in particular here. I use it
every day and am grateful for its existance, and look forward to the point
where migrating to version 4 is going to be relatively painless, at which
point I'll actually give that another try.

But on the whole, it's like nobody in the JS world seems to learn from the
mistakes of other JS projects and they have to make them again themselves.

------
Zalastax
I know that this is tongue in cheek , but shouldn't we give the maintainers
time to solve the documentation before we start complaining too much? The
changes they are making seems to make sense to me. They are adopting patterns
that the community uses and provide solutions to hacks that have emerged from
real needs. Webpack was in my opinion already simple, and it's getting simpler
every release. I can't imagine the horrible mess I would have if I went back
to gulp.

~~~
krankthat
Just like git tags, release notes, makefiles, etc ... Documentation is one of
those things that needs to be updated as part of a new release.

~~~
Zalastax
Yes, it could have been handled better. I guess you need to consider whether
it's best to let newcomers in on the v4 goodness or to avoid aliating users of
v3. The pragmatic approach is to at least mention somewhere that v3 users
should wait on upgrading.

------
alexdong
I keep telling myself: "embrace changes. an upgrade is great; new defaults are
cool; performance improvements are great; just do it; just do it".

Yeah.

One day.

PS. I do miss the days when you can just read a book and `man` your way around
the dev environment.

~~~
monaghanboy
I think your ideal exists in backend/SRE roles.

------
GabeRicard
Author of the gist here. Please don't take this as me complaining about
webpack 4 in any way. This was me detailing my process of migrating to the
webpack 4 BETA in order to provide feedback to the webpack team, and
potentially help anyone else out who got stuck on a few things like I did.

They're updating the documentation. Webpack is awesome and v4 is a great
update and I highly recommend people try it out.

~~~
disgruntledphd2
I think that this style of blog/info dump is really, really useful and speaks
to how I have spent many, many weekends.

Even though I don't really use much JS, I still got a real kick out of reading
this.

~~~
GabeRicard
Haha. Thanks! I am trying to do this more, just for personal notes about
projects. It makes it easier to go back later and remember what the pitfalls
were.

------
blueside
I've used Webpack on and off since v2 and I'm still no fan.

If I'm being honest, there's been times that it's perhaps been the worst dev
experience I've endured in the last decade.

Can we use Parcel as a replacement yet?

~~~
thelarkinn
Sure, but since your experience is not configuring anything, how are you going
to know what it's actually doing to your code. And what are the tradeoffs?
Seems like many don't have this answer because they don't have good
archetectural reasons for choosing it.

~~~
BigJono
For what it's worth, my experience with Parcel so far has been a show stopping
bug that makes CSS Modules unusable with it, was quite difficult to diagnose
(as with any bug in a dependency, I spent yonks looking at my own codebase),
and has so far gone un-fixed.

[https://github.com/parcel-
bundler/parcel/issues/378](https://github.com/parcel-
bundler/parcel/issues/378)

I don't see how this is really possible given the relatively high usage level
of CSS Modules, but whatever. I'm forced to stick with Webpack for the time
being.

------
jacquesc
Haha, pretty much my life every 3 months. Welcome to the new world of frontend
development.

Luckily the bad also comes with the good. Adding and upgrading components off
npm in a webpack project is almost always a breeze.

~~~
6t6t6t6
Another option is to wait just a couple of months to upgrade, so you give time
to the library developers to put their s __* together, fix bugs, and write
some documentation.

At the end, from all the features your users could care about, your webpack
version is not one of them.

~~~
slig
> Another option is to wait just a couple of months to upgrade

I did that when webpack 3 was released and now I'm two versions behind.

------
thelarkinn
PS: I submitted this response also in Reddit for those who come across it
twice. It's not meant to be disingenuous (as I'll likely respond to individual
comments also), just meant to show what our statement is.

Hi all,

We appreciate the feedback. So whether you care to know or not I'll explain
where we stand as a project for our docs.

So in this major release we want to try different ways to impact as many users
as possible. So this time we consiously put priority on working directly with
framework and tooling authors like angular, react, preact, vue to ensure they
were unblocked on implementing v4.

With this we decided: since plugins and loaders will also need time, we will
give them a month and release our final version without breaking changes from
RC. However I as a maintainer orchestrating all of our separate ecosystem,
docs, and teams didn't realise we had been behind on contributions and work
from our docs and when the 30 day window elapsed v4 shipped as promise.

To not hold back v4 with docs is an organizational and communication error on
my part and maybe even a side-effect of juggling my full-time job at Microsoft
and the 120-140 hours I spend a month on webpack.

I'm more then willing to own this, and for anyone frustrated, its on me and
I'm sorry. However we grow and improve after any mistakes we make. So, we have
some takeaways that we will build on for our next Major Release.

A complete migration guide will be a primary shipping dependency for any
future Major version of webpack going here forward. We learned that instead of
focusing on frameworks as heavily to provide impact and upgrade paths, (which
not have all done this yet), that instead focusing on content accessible to
everyone is a far more impactful result. For now, we have the PR pending for
our docs upgrade and I'll likely spend the majority of my free time ensuring
we have it ready to release as soon as possible. Thank you all for being
reasonable and patient with this.

Major version releases like webpack 4 are much less likely to happen. This
major release included the rewrite in our plugin system, which is the cause of
incompatible loaders and plugins. We have no plans to rewrite it again as it
is exactly where we need it to be in terms of performance, capabilities, etc.
Therefore, look to most future Major versions to be less severe and impactful
to loaders and plugins.

I plan to spend much more focus on ensuring all of our separate teams are
communicating for releases by coordinating all hands ship meetings. This
ensures that we are on the same page and everyone is aware what each team has
a dependency on.

We actually only do have one full time engineer. And have attempted to fully
fund a documentation team to work on it full time! It takes a considerable
amount of effort to do right. And so thanks for understanding while we
continue to work on it. Contributions are always welcome along with
constructive feedback.

Regardless, we appreciate as always support the positive comments we've seen
here but also the actionable criticisms. It probably sounds redundant but we
really stress the high bar and expectations that are set for us in the
ecosystem as so many of you rely on webpack to ship your products and
solutions to the web. We will keep on improving as we have since 2012 and hope
you all continue to help us along the way.

Sean + webpack Team (@TheLarkInn)

~~~
isuckatcoding
Hi Sean.

I certainly didn't mean to bring you down or disparage the work of the webpack
team/project in anyway. For me, the way the gist itself was written was just
too funny.

Anyways, thank you for all your hard work.

~~~
thelarkinn
I honestly don't feel you did! In fact this gist we actually had from a
contributor kind enough to document his experience so we could identify
exactly what hot path migration would look like for users. So we were really
happy to have this gist created. And we have it tied to our docs PR/issues :)

------
simon04
There's a big webpack 4 documentation update PR in the pipeline:
[https://github.com/webpack/webpack.js.org/pull/1856](https://github.com/webpack/webpack.js.org/pull/1856)

------
knackers
Went through this exact process last week. Did they really need to remove
CommonsChunkPlugin? Feels like breaking stuff for a slightly nicer API. If
this were React we would've had a deprecation warning for a few versions.

~~~
shakna
> If this were React we would've had a deprecation warning for a few versions.

If this were React, you would have got docs with a release.

Choosing to release before documentation is done, for a tool developers are
supposed to use as a black box, which has a lot of strange configuration that
is required, is a really strange choice for something with so many breaking
changes.

~~~
Zalastax
They haven't released webpack 4 yet.

~~~
shakna
They have [0][1] ("beta" was dropped from the v4 releases at v4.0.0), and are
actually in the process of updating the documentation [2]. It's just odd to do
that after a release.

[0]
[https://www.npmjs.com/package/webpack](https://www.npmjs.com/package/webpack)

[1]
[https://github.com/webpack/webpack/releases](https://github.com/webpack/webpack/releases)

[2]
[https://github.com/webpack/webpack.js.org/pull/1905](https://github.com/webpack/webpack.js.org/pull/1905)

~~~
Zalastax
Whoops, guess it's a good idea to check things before blurting something out.
In that case I'm not sure what's best, to let newcomers in on the new goodies
of v4 or to avoid confusing previous users.

------
Vinnl
The upgrade seemed relatively straightforward with the release blog post.
Really, it's the fact that many plug-ins will have to be updated that is
holding the upgrade back, but that's not _that_ much of a problem: I've simply
documented the status of each [0], am following the respective
issues/preparing to submit PRs myself if needed, and am meanwhile remaining on
v3.

[0]
[https://gitlab.com/Flockademic/Flockademic/issues/306#note_6...](https://gitlab.com/Flockademic/Flockademic/issues/306#note_60571871)

------
isuckatcoding
So I found this gist as I was googling for my webpack error. Originally was
trying to get the uglify plugin to work. Then I said screw uglify and STILL
couldn't get it work.

I gave up and ended up using Rollbar.

------
mratzloff
OK, so faster builds—and what else? Why not wait until documentation catches
up and spare yourself the trouble?

~~~
GabeRicard
Because I was just trying it out? Are you saying it's wrong to test a beta and
provide feedback to the authors?

~~~
mratzloff
Sure, that's perfectly fine. I interpreted your original post as a public
warning or complaint to other users. You've updated the Gist since then with a
big disclaimer, so perhaps I wasn't the only one.

More broadly, I often see developers stay on the cutting edge when they don't
have a security or feature need to, then complain about it.

------
pacifika
Stop guessing start learning. It sounds like the person doesn’t understand
what each configuration command does.

~~~
GabeRicard
I'm the author of the gist. You're exactly right. This was me guessing when I
didn't understand the configuration options, because this was my attempt at
learning the BETA of webpack 4 without the new docs available.

------
mnm1
Angular, brunch, babel, webpack. While not limited exclusively to the JS
community, it seems that much of the JS community especially does not care
about backwards compatibility or long term support. Piling on new features and
re-architecting everything with every major version number, and sometimes even
with minor version numbers, seems to have taken over actually creating and
maintaining useful products to the detriment of all software that uses such
products. Now we end up with software that's dependent on literally un-
upgradable components that are no longer supported and in some cases do not
even get security patches. With certain breakages, the software cannot be
built at all. Perhaps it might not be a bad idea for open source developers to
include a small section in their documentation that details their intended
philosophy for the future of the software. That way, people don't get duped
into using software written by teams that plan to abandon it completely (I'm
looking at Angular here) or partially (everything else).

