What is the size impact of importing one method from date-fns

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.


$ 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.


$ 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      ...


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


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.