The webpack module bundler.
View All Tags
Back in 2021 I published a post called ts-loader goes webpack 5; a big exciting post about how ts-loader was upgraded to directly support webpack 5, and drop support for webpack 4 in v9 of ts-loader.
For reasons which I'll get into shortly, as of v9.6.0, ts-loader now supports both webpack 5 (as it did already) and webpack 4. So if you're a webpack 4 user, you can now use ts-loader@9, rather than using ts-loader@8.
If you're a JavaScript developer, you've probably heard of webpack. It's a JavaScript bundler that helps you bundle your code into a single file. It's a great tool for optimizing your code and improving performance. This article will give you an overview of webpack, its history and how it works.
It'll be a little different than your typical "what is webpack?" article, in that I write this as the maintainer of ts-loader, a loader used for integrating TypeScript with webpack. I've worked in the webpack ecosystem for some years now and I'll share some of my experiences with you. I'll go through a little history around bundling, and try to understand why webpack came to be such a popular choice.
This post demonstrates how to speed up your Docusaurus build by using SWC and the swc-loader for webpack.
When we're using custom fonts in our websites, it's good practice to preload the fonts to minimise the flash of unstyled text. This post shows how to achieve this with Docusaurus.
Builds can be made faster using tools like esbuild. However, if you're invested in webpack but would still like to take advantage of speedier builds, there is a way. This post takes us through using esbuild alongside webpack using esbuild-loader.
Docusaurus doesn't ship with "blog archive" functionality. By which I mean, something that allows you to look at an overview of your historic blog posts. It turns out it is fairly straightforward to implement your own. This post does just that.
As of v2.0.0-beta.6, Docusauras does ship with blog archive functionality that lives at the archive route. This is down to the work of Gabriel Csapo in this PR.
If you'd like to know how to build your own, read on... But you may not need to!
ts-loader has just released v9.0.0. This post goes through what this release is all about, and what it took to ship this version. For intrigue, it includes a brief scamper into my mental health along the way. Some upgrades go smoothly - this one had some hiccups. But we'll get into that.
The fork-ts-checker-webpack-plugin has, since its inception, performed two classes of checking:
Yarn PnP is an innovation by the Yarn team designed to speed up module resolution by node. To quote the (excellent) docs:
I'm one of the maintainers of the fork-ts-checker-webpack-plugin. Hi there!
It's time for the first major version of fork-ts-checker-webpack-plugin. It's been a long time coming :-)
All I ask for is a compiler and a tight feedback loop. Narrowing the gap between making a change to a program and seeing the effect of that is a productivity boon. The TypeScript team are wise cats and dig this. They've taken strides to improve the developer experience of TypeScript users by introducing a "watch" API which can be leveraged by other tools. To quote the docs:
It all started with a GitHub issue. Ernst Ammann reported:
So project references eh? They shipped with TypeScript 3. We've just shipped initial support for project references in ts-loader v5.2.0. All the hard work was done by the amazing Andrew Branch. In fact I'd recommend taking a gander at the PR. Yay Andrew!
This post shows how you can use TypeScript with webpack alias to move away from using relative paths in your import statements.
I spent today digging through our webpack 4 config trying to work out why a production bundle contained code like this:
if("production"!==e.env.NODE_ENV){//...
My expectation was that with webpack 4 and 'mode': 'production' this meant that behind the scenes all process.env.NODE_ENV statements should be converted to 'production'. Subsequently Uglify would automatically get its groove on with the resulting if("production"!=="production") ... and et voilà!... Strip the dead code.
It seemed that was not the case. I was seeing (regrettably) undead code. And who here actually likes the undead?
webpack has long supported the notion of dead code elimination. webpack facilitates this through use of the DefinePlugin. The compile time value of process.env.NODE_ENV is set either to 'production' or something else. If it's set to 'production' then some dead code hackery can happen. Libraries like React make use of this to serve up different, and crucially smaller, production builds.
webpack 4 has shipped!
The first webpack 4 beta dropped on Friday. Very exciting! Following hot on the heels of those announcements, I've some news to share too. Can you guess what it is?