An attempt to upgrade to Webpack 4

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.

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

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.

According to Webpack's donation site, 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.

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.

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.

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.

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.

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.

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?

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.

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)

There's a big webpack 4 documentation update PR in the pipeline: https://github.com/webpack/webpack.js.org/pull/1856

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.

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

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.

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

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

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