In this article, I'll take a quick look at the build size of a simple code that imports a method from date-fns. I check results from both, webpack & esbuild.

The code

The code I use in this test is as follows:

import { sub } from "date-fns";

const today = new Date();

console.log("Yesterday was", sub(today, { days: 1 }));

In this way, I can:

1. Test the impact of an import of the code needed to do one simple operation
2. Check the output code quickly in the console log - so I don't compare working builds with broken ones.

Build scripts

The builds are run with:

webpack --mode=production

Standard webpack build, with production mode, set explicitly.

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

Fairly simple esbuild command, with --minify on & required --bundle flag.

The benchmark

Both wepback & esbuild performed pretty much the same.

Webpack

$ npm run webpack       

> date-fns-bundle-size@1.0.0 webpack
> webpack --mode=production

asset main.js 1.59 KiB [compared for emit] [minimized] (name: main)
orphan modules 546 KiB [orphan] 264 modules
./src/index.js + 8 modules 11.6 KiB [built] [code generated]
webpack 5.47.1 compiled successfully in 858 ms

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

The output size is about 1.6 KiB.

esbuild

$ npm run esbuild  

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


  dist/main.js  1.6kb

⚡ Done in 40ms

# stat dist/main.js
  File: dist/main.js
  Size: 1624      ...

Links

The test repo I've been using in this article is here.

Summary

In this article, we have seen the isolated impact of imports of one method from date-fns. In the following articles in this series, I'll look at other popular date manipulation libraries.