Tree shaking issue in v2.28
See original GitHub issueI use only a few of the functions and made sure I import them as recommended for tree-shaking in the documentation :
import { parse } from 'date-fns'
import { fr } from 'date-fns/locale';
The code itself works fine, but when I look at the resulting JS bundle, the entire library (date-fns/esm) along with all of the locales are bundled, resulting in ~1,49mb > parsed 607kb > Gzipped 118kb. I use NuxtJS (bundling with webpack) and the latest date-fns (2.28.0 as of today).
Here is a picture of the bundle generated :
I initially posted my issue on StackOverflow here for the issue and tried several solutions from these older issues #2207 , #2589 and from these SO answers
Specifically, this is not working :
import parse from "date-fns/fp/parse";
import fr from 'date-fns/locale/fr';
Unfortunately, no matter how I import the functions, the bundle keeps including all functions and all locales, so I am starting to suspect it may come from the date-fns library itself.
Issue Analytics
- State:
- Created a year ago
- Reactions:3
- Comments:6
Top GitHub Comments
Thanks for the replies !
⚠️⚠️ The following workaround works, but I still believe there should be some kind of fix coming from date-fns itself to avoid these messy fixes and allow simply importing ⚠️⚠️
Regarding the locales, the workaround given here seems to work for me. It solved part of the problem for me and greatly reduced the bundle size.
I’ve tried to use the same approach but haven’t worked out how to achieve the same result for the actual date-fns functions.
⛔ Following did not work for the functions
Created a file called
date-fns-functions.js
where I re-export the functions used in the project like this :Then, adding an alias in the Webpack config :
In my particular case, using Nuxt.js for Webpack bundling I added this in nuxt.config.js instead :
This seemed to work fine in the bundle generation (I can see only the functions I import) BUT at runtime I get errors saying the functions are not defined.
Aha, I think I found out what’s causing the problem for me: https://github.com/react-component/picker/issues/232
So, ultimately, this is probably nothing to do with date-fns itself.