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.
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.
The code I use in the benchmark is:
import dayjs from "dayjs"; console.log("Yesterday was", dayjs().subtract(1, "day").toDate());
The build scripts I use are:
$ webpack --mode=production
$ esbuild src/index.js --outfile=dist/main.js --bundle --minify
And the results are as follow:
npm run webpack > firstname.lastname@example.org 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.
$ npm run esbuild > email@example.com 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.
The benchmark repository.
In this article, I have shown the size impact of day.js on the build size.