I suspect that the Webpack team thinks that developers' favourite job is to upgrade tool configurations. I mean, it's great that improvements are being made, but breaking changes are not.<p>Remember that the Webpack team has shown to be actively hostile to people who just want to keep their 2-year-old codebases work without doing needless upgrade work. They <i>removed</i> the webpack 1 docs [1], so if you have a few-years-old codebase that you want to get up and running, and somehow you get a webpack error, the message from Webpack is "screw you, upgrade to webpack 3 first and only then we'll allow you to read the docs".<p>I have no reason to not expect the same to happen with Webpack 4, and the inevitable Webpack 5, 7 months from now. Webpack 2/3 docs will be subtly removed, retired and forgotten. We're all forced to keep doing work to make something work that already worked perfectly fine.<p>Now, I'm well aware that an angry rant on the internet about the voluntary work from open source contributors is not particularly constructive. I've singled out the Webpack team here, but the reality is that a big part of the web dev ecosystem, across languages, does not care much about backward compatibility. I'd love for that attitude to change.<p>In semver, every major version is a tragedy.<p>[1] <a href="https://webpack.github.io/docs/using-plugins" rel="nofollow">https://webpack.github.io/docs/using-plugins</a>
Do you remember the time when you just copied your file over to the server, and magically everything was deployed? I do. It was a good time. Yes, I am old.<p>In search for something that makes me work like the good old times, but with modern javascript solutions, I stumbled upon mod_pagespeed[1]: it minifies your javascript and html, optimizes images, and more or less does what webpack does (minus the typescript -> js compilation).<p>The good old times are back for me: deploying is now an scp away.<p>For important projects I copy the static assets to the server, let jenkins run integration tests on staging and if everything works as expected just copy it over to production. One less thing to worry about for me.<p>[1]<a href="https://www.modpagespeed.com/" rel="nofollow">https://www.modpagespeed.com/</a>
These look really solid!<p>For anyone else who was confused by the minimal explanation of the "sideEffects: false" feature, apparently this targets cases where (1) module A exports some code, (2) module B imports from A and exports end points, some of which depend on A, and (3) module C imports code from B that doesn't reference code from A.<p>In this situation by default webpack assumes that the code from A might have side effects inside B, but if A declares "sideEffects: false" in its package.json, the tree-shaker will assume it's safe to omit module A from the final bundle.<p>Incidentally the end user can also declare in their config that module B should use sideEffects:false, even if the module doesn't declare it. Details here: <a href="https://github.com/webpack/webpack/issues/6065" rel="nofollow">https://github.com/webpack/webpack/issues/6065</a>
One of things I absolutely despise about the JS community is this obsession with build tools. JS is meant to be a runtime language and the amount of transpilers, minifiers, uglifiers, obfusicationifiers, is absolutely endemic to the messy state of change the language is undergoing.<p>However with this release I'm excited to start deleting a bunch of ridiculous build code to make Webpack work. Really a build tool is a tool, it should never be in the way of developing features. I haven't enjoyed using webpack until now. No sensible defaults, poor documentation, and no standard conventions. This release changes all of those complaints. A boost for productivity is a win in my book.
As a web dev I am extremely happy Webpack team changed their stance from "webpack config is the way it is because everyone's needs are different and also because that's just how Javascript works" to "yes, we can provide sane defaults out of the box".<p>Aaand that their communication has improved a thousand-fold.
Two years ago I would have invested some effort to read this thoroughly and try to stay on top of the API changes. I'm sure it's helpful to a lot of folks.<p>For sure I do care about my build toolchain. The nice thing about being a React developer today, is that thanks to create-react-app, more specifically react-scripts [1], I'm thankful I get to choose to not worry about it. Just like I didn't have to worry about 2.0 -> 3.0 last time.<p>Cheers to the CRA maintainers. Thanks for giving me some time back!<p>[1] <a href="https://github.com/facebook/create-react-app/blob/next/packages/react-scripts/package.json#L62" rel="nofollow">https://github.com/facebook/create-react-app/blob/next/packa...</a>
Is there really any point to webpack now that we have http2? I'm looking for a way to code split all the things and webpack is making that difficult. I want cache performance over download speed now that I've gone mobile only on data.
I've been running the alpha, to help get past the Webpack/Uglify ES6 support issues.<p>It sounds like webpack-dev-server will also disappear soon, too? (Replaced with a more tightly integrated solution, or?)
Oh good. I just finished upgrading my project to Webpack 3. Can't wait to do it all again...<p>I'm all for rapid progress, but the pace of web development is absolutely breakneck.
A few years ago I was asked by a frontend team to investigate their Jenkins build. What used to take 90 seconds went to 15 minutes and it only started happening when the team switched to Webpack. I recall Webpack being hideously complicated with a lot of the documentation either missing or just plain wrong - no wonder they managed to make a mess of things so easily. Has any of that changed?
I don't use Webpack, would it help with regular website dev? Or is this just for web apps?<p>Also, does it really make things faster? What about HTTP2/SPDY, do we really care about making everything one file anymore? This seems like a paradigm that is no longer valid (like using tables instead of grid for website layout).
I use Browserify and it works great.<p>Maybe there are some legitimate cases in which you would prefer Webpack, but I really don't understand why have EVERYBODY migrated to Webpack, with all its bloat and breaking changes and build errors and boilerplate.
Shameless promotion<p><a href="https://rollupjs.org" rel="nofollow">https://rollupjs.org</a> - JS module loader with tree shaking and async loader that works out of the box.<p>Asynchronous loading and code<p>Take a try if webpack takes toll on your productivity