[HN Gopher] Webpack 5
___________________________________________________________________
Webpack 5
Author : marksamman
Score : 99 points
Date : 2020-10-10 20:12 UTC (2 hours ago)
(HTM) web link (webpack.js.org)
(TXT) w3m dump (webpack.js.org)
| bichiliad wrote:
| I have to sing some praises for Webpack for a second. I work at a
| company with a large (> 10k files) old (> 10 years) JS codebase.
| It used to rely on a home-grown build tool, but making our builds
| both fast and modern took the time of multiple full-time
| engineers. Webpack isn't "fast" like Rust is fast, and it's not
| old enough to be as well-documented or understandable as I'd
| wish, but:
|
| 1. it is flexible enough to fit all of our weird edge cases.
|
| 2. it has a really solid community of people working on it.
|
| 3. it made adopting new features like TypeScript extremely simple
| for us.
|
| I don't see us upgrading from 4 to 5 eagerly (at least until it's
| been production-proven), but I'm excited about this release, and
| I love all the hard work that's gone into it. Congrats to the
| team -- it's no small feat.
|
| Edit: formatting
| null_deref wrote:
| I don't use webpack anymore, but I have to say it was nice
| reading your story, I aspire to build a product which users
| will appreciate like this.
| WesolyKubeczek wrote:
| So I guess it's safe now to try migrating a project from Webpack
| 3.x to 4.x?
| nikivi wrote:
| Eventually the packing part can be done in a compiled language.
| https://github.com/evanw/esbuild is very fast at doing some
| things already but not others.
|
| And I guess webpack wins because you can configure it to do
| anything easily already? And with compiled languages
| 'configurability' is hard to do?
| simonw wrote:
| I've been putting off learning Webpack for far too long.
|
| Can anyone provide some kind of a syllabus to help me figure out
| what there is to learn about it, starting from almost no
| knowledge at all?
|
| I feel like it's a critical enough piece of modern web
| infrastructure that it's worth me taking the time to fully
| understand how to use it and what it's capable of.
| idointernet wrote:
| https://survivejs.com/webpack/
| jiofih wrote:
| Nah.
|
| EDIT: ok, some more context. You should be glad you haven't had
| to deal with this shit show yet. Don't walk willingly into it,
| there are much less painful tools like Rollup, Vite and Parcel
| around.
| faichai wrote:
| This pretty much nails the problem with Webpack in my view. It
| doesn't seem to be based on any kind of strong, logical, easy
| to understand core, but instead is comprised of lots of
| interwoven threads of magic that no-one really understands.
|
| This makes any attempt to debug and solve problems with it a
| total nightmare, like crawling through a tar pit. You might
| make it, but you're gonna feel all sticky and dirty coming out
| the other side.
|
| That said, kudos to the developers, I use it every day, but I
| wish it were a lot simpler.
| jebronie wrote:
| "There is a good chance that upgrading fails and you would need
| to give it a second or 3rd try."
|
| Sad that this has almost become the norm when developing in the
| modern javascript ecosystem. I dread touching those projects and
| creating one even more because stuff just rots away and your app
| might break in days, weeks or If you are lucky months. I'm sure
| there are better developers out there that can handle all of this
| and know how to avoid it, but a bozo like me does not. This is
| actually causing me stress irl.
| vmception wrote:
| Oh thats because you are missing the specific version _manager_
| for each part of your build toolchain
|
| And dont forget to make a script that automatically sets the
| right versions of npm, webpack, and python all at once!
|
| This is fine, I am okay with the events that are unfolding
| currently.
| zdragnar wrote:
| If you have multiple projects of _almost_ any language that
| are stuck on different versions, you basically end up with
| the same problem and solution.
|
| I will definitely keep my version managers, thank you very
| much.
| haar wrote:
| I've been using ASDF (https://github.com/asdf-vm/asdf) for a
| while now to manage each of the language (and sometimes build
| tool) versions for a folder/repo in a consistent manner. I'd
| definitely recommend taking a look at it.
| throwanem wrote:
| The way you avoid problems with a .0.0 release is by not
| upgrading to a .0.0 release. You would have to do that by hand;
| npm and yarn have been pinning major versions for a long time
| now, so that upgrade only happens when you do it by hand. So if
| you don't want to deal with breaking changes, all you have to
| do is nothing. Meantime webpack 4 is not going anywhere.
| SilasX wrote:
| I'm reminded of when npm released 5.7.0 (which some got
| upgraded to automatically because it wasn't tagged as pre-
| release) and had a critical bug that deleted your system
| files.
|
| https://news.ycombinator.com/item?id=16435305
| throwanem wrote:
| Why? What on Earth do you imagine that having to do with
| this?
| GordonS wrote:
| I frequently have to rerun `npm i` when it fails for seemingly
| spurious reasons. We used to laugh at Windows years ago, when
| the solution was so often "turn it off and on again", but it's
| basically what you need to constantly do with tools like npm
| and webpack.
| nicoburns wrote:
| Yarn is much better in this regard. I'd thoroughly recommend
| it. It's drop-in compatible (except it will generate it's own
| lock file), so it's pretty easy to try it.
| tqkxzugoaupvwqr wrote:
| It helps to pin dependencies so that only the exact specified
| version is downloaded/installed/used.
|
| I recently updated the dependencies of a frontend project.
| `vue-apollo` from version 3.0.3 to 3.0.4 had a breaking change.
| The discussion in the commit on GitHub proposed to release it
| as v4. But in the dev's mind it was a fix so he released it as
| a patch version.
| root_axis wrote:
| Why do you feel the need to upgrade to webpack 5? What
| particular feature do you need that justifies the upgrade?
| sinker wrote:
| So far what I've been doing is keeping my webpack config as
| simple as possible (< 40 lines) and just relying on default
| behavior. I know I'm losing out by not bothering with some of
| the more intricate configuration properties like caching, etc.
|
| But one of my big pet peeves is when you clone a project and
| the installation says all you need to do is run make install or
| npm i, but in reality requires 20 google searches and an hour
| of banging your head to get the project running and even then
| you end up with 50 cryptic warning messages in your terminal so
| you don't even know if you did it correctly.
|
| With a very simple webpack config you might lose out on
| optimizations but at least you can get just about anyone
| running a project locally and if things go awry you can
| generally pinpoint the problem to a specific line of
| configuration.
| nicoburns wrote:
| I've found that a slightly longer (~100 lines) webpack config
| allows me to use all the caching and fancy tricks I want and
| is still just as debuggable. I think the main thing is
| setting it up yourself so you know what all the
| plugins/settings do.
| nwienert wrote:
| The key is don't abstract it. No function builders, one big
| object with inline conditional spreads.
| jakub_g wrote:
| Webpack is kind of more "build your own bundler" than a
| bundler. The configurability and extensibility is immense and
| with that level of complexity, it's guaranteed things won't
| work smoothly for everyone (incompatible plugins, unexpected
| configurations etc.). Anyway, every big project always has
| hiccups with new major X.0.0 release.
|
| Think about your own code for a second. It's typically a well
| defined code that doesn't have to accommodate a combinatorial
| explosion of configurations. It is bug free?
|
| Keep in mind that 90% of code is written by one guy. It's not
| Webpack Corp. with a legion of QA testers.
| setr wrote:
| Run it three times however is not part of such bugginess
| though. It means that they're randomly encountering different
| executions/run-states on what should be the same
| config/setup, each time you run it. And they have no idea
| why.
|
| Or they're running things in parallel, and encountering data
| races and such, and randomly working as a result.
|
| But the real concern is that they don't really know what a
| _correct installation_ looks like, or they 'd just check-and-
| retry on a loop until it succeeded (the easiest hack around
| such problems)
| ENGNR wrote:
| I think it's more if 5.0.0 doesn't work the first time, you
| could simply let the community find those issues for you
| and by 5.0.xx it will mostly likely cover your specific
| setup (except for the documented api changes)
| jacob019 wrote:
| I know the feeling. It's not just modern stuff, I have an old
| ExtJS app that I dread to update. The best solution I have
| found is a dev / build environment in a dedicated VM that I can
| spin up once or twice a year to make updates. Bringing
| libraries up to date is a fucking nightmare and often a waste
| of time. For continuously updated apps I have moved away from
| complicated build processes. Most web apps are fine without a
| build process, I think there is a lot of premature optimization
| going on.
| cjauvin wrote:
| I too maintain an old and complex ExtJS 4.1 app and I never
| dared upgrading the framework. I carry a big zip around and
| it will be that until the end of its life or when I finally
| decide to rewrite it using React. For such an old framework
| it's surprisingly bug free though.
| hsbauauvhabzb wrote:
| Out of curiosity is patching and updating all packages also a
| common consistent issue? Is there regularly breaking changes?
| ronaldj wrote:
| Configuring the modern JS toolkit (webpack, Babel, your
| framework of choice, Jest, etc) is such a pain. I've been doing
| front-end for 10+ years. You're probably not a bozo.
| folkhack wrote:
| Same, and it's just layer on layer of extra tooling and
| complexity.
|
| Typescript, Babel, Webpack, JSX, TSX, etc, etc.
|
| It gets in the way of development as much as it helps.
| Jarred wrote:
| The incremental build time improvements look great.
|
| Did the cold build times get slower? This tweet shows a benchmark
| that makes it seem like cold build times got slower in Webpack 5
|
| https://twitter.com/evanwallace/status/1314121407903617025?s...
| [deleted]
| ENGNR wrote:
| As someone who fought battles with webpack and webpack 2, I've
| since been pleasantly surprised that each upgrade has just gotten
| simpler and more stable, and I can progressively delete more of
| my own code as the features get built in. Big thanks to the
| maintainers!
| spiderjerusalem wrote:
| The last time I tried to bump webpacker from 3 to 4 at <dayjob>
| was absolute hell. The fancy chunk splitting logic was spewing
| out non-deterministic bundles across different machines in our
| infra. Took a lot of deep digging in the internal graph
| representation to find the root cause.
|
| I gave a local related meetup talk, slides here.
|
| https://vheis.su/slides/curing-webpack-cancer/#11
| acemarke wrote:
| Next.js 9.5 added opt-in support for Webpack 5:
|
| https://nextjs.org/blog/next-9-5
|
| and looks like Create-React-App plans to support Webpack 5 in an
| upcoming CRA 4.1 release (4.0 is in alpha now):
|
| https://github.com/facebook/create-react-app/issues/9613#iss...
| Waterluvian wrote:
| I'm scrolling and scrolling waiting for a paragraph that tries to
| sell me on why I'd bother and risk upgrading. I think the best I
| got were patch notes.
|
| Any good reason to upgrade?
| bichiliad wrote:
| The biggest thing I've been excited about is having an offline
| cache for fast recompilations. It'll make startup times a lot
| faster, which is a big improvement for developer experence
| (especially in larger codebases).
| marcins wrote:
| Up to a point, eventually when the code base is large enough
| you spend more time serialising/deserialising and passing
| things between workers that it can be faster to disable the
| cache.
| acemarke wrote:
| Per
| https://webpack.js.org/blog/2020-10-10-webpack-5-release/#ge...
| :
|
| - Improve build performance with Persistent Caching.
|
| - Improve Long Term Caching with better algorithms and
| defaults.
|
| - Improve bundle size with better Tree Shaking and Code
| Generation.
|
| - Improve compatibility with the web platform.
|
| - Clean up internal structures that were left in a weird state
| while implementing features in v4 without introducing any
| breaking changes.
|
| - Prepare for future features by introducing breaking changes
| now, allowing us to stay on v5 for as long as possible
| randtrain34 wrote:
| Are there any benchmarks to get a rough idea on how much
| improvement in all these areas we can expect to get by
| upgrading?
| xwdv wrote:
| The only benchmark that matters is how much more money you
| will make from customers after upgrading.
| dmitryminkovsky wrote:
| Put that coffee down! Coffee is for closers only.
| lhnz wrote:
| I've heard that build performance is actually worse than
| webpack 4, if you're not using persistent caching. See:
| https://twitter.com/FredKSchott/status/1314220659984146432
| nicoburns wrote:
| From that thread:
|
| The benchmark is dominated by terser and SourceMap
| performance. What you see are different terser
| configurations. Webpack 4 with compress.passes: 1 and
| webpack 5 with compress.passes: 2. Enabled SourceMaps makes
| minimizing extra expensive.
| jholman wrote:
| MacOS's broken-ass filesystem will no longer be allowed to
| cause warnings on other operating systems, that's a feature I'm
| keen about!
|
| (removal of the dependency on chokidar and fsevents)
| foota wrote:
| I'm excited for async module loading for web assembly.
| SimeVidas wrote:
| If anyone at webpack reads this, consider adding an RSS feed to
| your blog.
| montogeek wrote:
| Interesting, it is not a blog per se. But we can build one,
| will take it into consideration.
| mminer wrote:
| Seconded. RSS is how I stay abreast of project updates. For
| ones like Webpack that lack RSS, GitHub's releases feed can be
| a substitute: https://github.com/webpack/webpack/releases.atom
___________________________________________________________________
(page generated 2020-10-10 23:00 UTC)