dont bundle everything in one file / should not require @mui/x-date-pickers unless used

[srghma]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Current behavior 😯

import { FormContainer, TextFieldElement } from 'react-hook-form-mui'

throws in webpack

ERROR in ./node_modules/react-hook-form-mui/dist/esm/index.js 1:6095-6155
Module not found: Error: Can't resolve '@mui/x-date-pickers/DatePicker' in '/app/node_modules/react-hook-form-mui/dist/esm'
 @ ./app/javascript/packs/entries/application/conference/App.js 22:0-70 219:66-79 224:38-54
 @ ./app/javascript/packs/entries/application/conference/index.js 14:0-24 28:44-47
 @ ./app/javascript/packs/application.js 42:0-42

why ? because package bundles everything in one file

[nix-shell:~/projects/asdf]$ tree /home/srghma/projects/asdf/node_modules/react-hook-form-mui
/home/srghma/projects/asdf/node_modules/react-hook-form-mui
├── dist
│   ├── date-fns.d.ts
│   ├── date-fns.js
│   ├── date-fns.js.map
│   ├── esm
│   │   ├── chunk-FJYXLP4R.js
│   │   ├── chunk-FJYXLP4R.js.map
│   │   ├── date-fns.js
│   │   ├── date-fns.js.map
│   │   ├── index.js
│   │   └── index.js.map
│   ├── index.d.ts
│   ├── index.js
│   └── index.js.map
├── LICENSE
├── package.json
└── README.md

2 directories, 15 files

Expected behavior 🤔

expected

allow import as

import FormContainer from 'react-hook-form-mui/FormContainer'
import TextFieldElement from 'react-hook-form-mui/TextFieldElement'

similar to how mui itself allows

import Alert from '@mui/joy/Alert'
import Stack from '@mui/joy/Stack'

[dohomi]

add the peerDependencies, they will be stripped out of your bundler

#  yarn add @mui/x-date-pickers @mui/icons-material

[sadik-malik]

@dohomi I think the concern here is about the way components are imported from react-hook-form-mui.

In mui, we can import components using both named import as well as path import.

// Named import
import { TextField } from '@mui/material';

// Path import
import TextField from '@mui/material/TextField';

Named imports are good for a better development experience but it can lead to slower startup times as it can contain the full library code.

Mui has documented this in their guide for minimizing bundle size.

https://mui.com/material-ui/guides/minimizing-bundle-size/

Also, If we can move components for @mui/x-date-pickers to a different package it would be better because it is possible not everyone is going to use those components.

[dohomi]

is that really a concern nowadays? Isn't everyone using modern tools like Vite or NextJS which have very fast startup times? We could have a look for v7 if it make sense to support additional exports, but I find it rather confusing if there are multiple approaches, not sure if MUI will keep the path imports in v6 though

[sadik-malik]

Modern tools, such as Vite or NextJS, do have an exceptionally rapid startup time. However, when dealing with projects that have a large number of components, the use of barrel files can result in slower updates during Hot Module Replacement (HMR) and longer startup times.

I have found these two articles from Vite and NextJS for optimizing performance and avoiding the use of barrel files

Vite documentation: https://vitejs.dev/guide/performance#avoid-barrel-files
Next.js blog post on optimized package imports: https://vercel.com/blog/how-we-optimized-package-imports-in-next-js

[aautem]

The way the installation section is worded right now makes it seem like the peer dependencies are supposed to be optional:

This package utilizes pickers and icons of the MUI ecosystem. If you make use of it add them to your app.

[dohomi]

closing in favour of #252