[docs][pickers] Document the bundle size impact of the various adapters

[ruifernando7]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Current behavior 😯

I'm usingimport AdapterDateFns from '@mui/lab/AdapterDateFns'; to make custom dateAdapter for LocalizationProvider. After that, i try to build it with webpack on mode production. The tree shaking not working for this library

I took about 254 kb which too large

Expected behavior 🤔

The size should be lower than that

Context 🔦

No response

Your environment 🌎

`npx @mui/envinfo`

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

[flaviendelangle]

Hi

Thanks for your report
Could you tell me which version of our packages you are using (you can use npx @mui/envinfo to generate a detailed report).

[ruifernando7]

Hi @flaviendelangle!,
Here's the mui deps that i used

"@mui/lab": "^5.0.0-alpha.83",
"@mui/material": "^5.8.1",
"@mui/styles": "^5.8.0",
"@mui/system": "^5.8.1",

and the result of npx @mui/envinfo

 System:
    OS: Windows 10 10.0.19043
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
    Memory: 6.29 GB / 23.89 GB
  Binaries:
    Node: 12.18.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.17 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 7.21.1 - C:\Program Files\nodejs\npm.CMD
  Utilities:
    Git: 2.27.0. - /mingw64/bin/git
  Virtualization:
    Docker: 20.10.11 - C:\Program Files\Docker\Docker\resources\bin\docker.EXE
  SDKs:
    Windows SDK:
      AllowAllTrustedApps: Disabled
  IDEs:
    VSCode: 1.63.2 - C:\Users\asus\AppData\Local\Programs\Microsoft VS Code\bin\code.CMD
  Languages:
    Bash: 4.4.23 - C:\Program Files\Git\usr\bin\bash.EXE
    Go: 1.14.7 - C:\Go\bin\go.EXE
    Perl: 5.30.2 - C:\Program Files\Git\usr\bin\perl.EXE
    Python: 3.9.6 - /c/Users/asus/AppData/Local/Programs/Python/Python39/python
  Browsers:
    Chrome: 102.0.5005.63
    Edge: Spartan (44.19041.1266.0), Chromium (101.0.1210.53)
    Internet Explorer: 11.0.19041.1566

Thanks!

[flaviendelangle]

Did you try migrating from the lab to our new package ?
The lab is re-exporting the pickers from @mui/x-date-pickers but they will be removed from the lab in a few weeks.
I don't think it will change a lot the problem here though...

I'll try to have a look

[ruifernando7]

@flaviendelangle I just tried it and the tree shaking still not working properly

[flaviendelangle]

I think the problem is directly in @date-io
If I do a simple Create React App importing '@date-io/date-fns', I get a bundle of 471kb (without React deps)
If I do the exact same app, without importing '@date-io/date-fns', I get a bundle of 209kb.

The diff of 262kb being close to what you get through @mui/x-date-pickers

[lytovka]

Hey @flaviendelangle, any luck figuring out how to reduce the bundle of '@date-io/date-fns' in AdapterDateFns? I saw your ongoing discussion with @date-io maintainers, but I'm not sure what direction this will eventually take for this project. Curious if bundle size improvements such as this one are on the roadmap at the moment.

Thanks!

[flaviendelangle]

Hey

We did not have the time to focus on that aspect yet 😬
I'll add this issue to our board to push it a little

[joshkel]

If I understand correctly, the problem is that it's hard to do tree-shaking on ES classes such as the date-io project uses. (date-io's purpose is to say, "Here's a standard date/time abstraction that you can pass to any third-party library you want, and date-io will support any method calls that third-party library wants." So it has to import every date-fns function that it might need to implement any of its API methods.)

If I use @date-io/date-fns with @mui/x-date-pickers, run webpack-bundle-analyzer, and enable its "Show content of concatenated modules (inaccurate)" option, then I can see that it is importing individual date-fn functions, as desired - it just needs a lot and is not able to do much tree-shaking.

[flaviendelangle]

If it only imports content that is being used on the adapter (even on method you are not using), then I agree that it is the expected behavior.

Most of the code is in very common method (like parse / format) that are used all over the place, so we won't be able to optimize much.

I have the feeling the date-fns is significantly heavier than dayjs, which we also support.
It may be interesting to add on the doc the bundle size added by each of these libraries, when used on the pickers (for dayjs we use plugins so the size advertised on their website is not realistic).

[andriijas]

Feels wierd that the date-fns adapter is so much heavier than the dayjs one

but the picker and grid is also heavy, so i created a new issue with cloneable repo
#7332