In this article, I'll take a look at the size impact of importing luxon. I'll check with both webpack & esbuild.

The code

Similar to the date-fns article in this series, I'm testing with a rather simple code:

// import trick from https://github.com/moment/luxon/issues/854
import { DateTime } from "luxon/src/luxon";

console.log("Yesterday was", DateTime.now().minus({ day: 1 }).toJSDate());

The import is modified from import { DataeTime } from 'luxon'; that you can find in the documentation. It improved the build size a bit, but not enough.

The build scripts

For my benchmark, I build code with:

webpack --mode=production

production mode set explicitly in webpack, and

esbuild src/index.js --outfile=dist/main.js --bundle --minify

Minification on in esbuild.

The benchmark

Both bundlers performed similarly in regards to size; of course, esbuild is much faster.

Webpack

$ webpack --mode=production

asset main.js 58.3 KiB [emitted] [minimized] (name: main)
orphan modules 217 KiB [orphan] 24 modules
./src/index.js + 23 modules 216 KiB [built] [code generated]
webpack 5.47.1 compiled successfully in 1749 ms

$ stat dist/main.js 
  File: dist/main.js
  Size: 59710       

The output size is 58.3 KiB

esbuild

$ npm run esbuild  

> luxon-bundle-size@1.0.0 esbuild
> esbuild src/index.js --outfile=dist/main.js --bundle --minify


  dist/main.js  58.5kb

⚡ Done in 18ms
$ stat dist/main.js
  File: dist/main.js
  Size: 59929  

The output size is 58.5KiB

Links

You can find my test repository here.

Summary

In this article, we have seen a size impact of importing luxon to our project. Unfortunately, luxon doesn't support tree shaking, so for doing only 1 operation with it, we need to import the whole library. And for doing so, we get a serious size penalty to our project. I will not consider this library for my projects, and I'm really curious about use-cases when it's doing better than other libs discussed in this series - if you have any, please let me know in the comments.