In this article, I'll take a look at how much the build size increases when you add Day.js library for date object manipulation.

Library

Day.js is an interesting library that implements a similar API as moment.js but with a smaller overhead. Because it's implementing the same fluent interface, tree-shaking is not possible with it, but the library looks promising size-wise anyway.

Code

The code I use in the benchmark is:

import dayjs from "dayjs";

console.log("Yesterday was", dayjs().subtract(1, "day").toDate());

It's the same logic I have in the luxon & date-fns example.

Build scripts

The build scripts I use are:

$ webpack --mode=production

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

Benchmark

And the results are as follow:

Webpack

npm run webpack  

> day-js-bundle-size@1.0.0 webpack
> webpack --mode=production

asset main.js 6.64 KiB [emitted] [minimized] (name: main)
runtime modules 663 bytes 3 modules
cacheable modules 6.43 KiB
  ./src/index.js 95 bytes [built] [code generated]
  ./node_modules/dayjs/dayjs.min.js 6.34 KiB [built] [code generated]

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

The build output is 6.64 KiB. The webpack build is still pretty quick, contrary to the luxon benchmark, which was noticeably slower than esbuild.

Esbuild

$ npm run esbuild   

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


  dist/main.js  7.0kb

⚡ Done in 4ms

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

The esbuild output is 7.0KiB, which is about 5% bigger than the webpack one.

Links

The benchmark repository.

Summary

In this article, I have shown the size impact of day.js on the build size.