The webpack module bundler.
View All Tags
ts-loader 10.0.0-beta.0 has shipped. It's a ground-up rewrite of ts-loader's compilation engine, built on the new native API that ships with TypeScript 7.1. This post covers how to install it, how to test it, and, importantly, what isn't in v10 and why.
TypeScript is now the most popular programming language. Incredible. I was an early adopter back in 2012 and have since worked on a number of open source projects in the TypeScript ecosystem.
One of them is ts-loader, which integrates TypeScript the language with webpack; which is used to build web applications. You might be surprised to know ts-loader has 54 million downloads a month. I know I am. I'll be honest - I'm using Vite far more than I use webpack these days, but there are still a lot of people using webpack and ts-loader. And I intend to continue to support them.
Just lately, TypeScript was ported from being written in TypeScript to being written in Go. The reason being for performance - make TypeScript tooling 10x faster. TypeScript 7 is written in Go.
This has implications for ts-loader as it is built on APIs the TypeScript library exposed. But those APIs were not ported to TypeScript 7. New ones are being written, recently I heard that the first emit APIs had landed in the nightly version of TypeScript.
It's been a rough year. In March I was diagnosed with a serious illness. I've written about my diagnosis on my personal blog and I won't repeat what I said there here. But the TL;DR is this: I was told that without treatment things looked bleak. Happily, there was a follow up sentence; there is treatment and I am now having it. Whilst nothing is guaranteed, the doctors have used phrases like "cautious optimism". Time will tell what happens, but I am hopeful that I will be around for a while yet.
However, this has made me think about the future of the open source projects I maintain. If I cannot maintain them anymore, what happens? That's what the title of this blog post means; what, or who, is the DR (that's Disaster Recovery not Daniel Rosenwasser) for my open source projects? Maybe there's a better term than "Disaster Recovery". Having worked on various systems over the years, I've often been involved in disaster recovery planning for them. It always comes down to answering this question: what takes over when everything goes wrong?
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.