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.
Top comments (0)