I am the maintainer of the React Query Builder (RQB) library. One of the features of RQB is that you can replace any internal component with a custom version for specialized behaviors and/or styling.
I'm considering publishing a new npm package that consists of prepackaged custom components for RQB. These would include AntD, Chakra UI, Material UI, and Bootstrap versions of most components (as seen in the demo - code here), a ValueEditor that uses react-datepicker, a FieldSelector that uses optgroups, and a few others.
For a build setup, I’m probably just going to copy the webpack configuration from the main RQB repo, since it works pretty well and does what I need.
My question is about tree shaking. If I publish a Bootstrap version of the ValueEditor component, how do I set up my dependencies so that if a user imports that component as shown below, they don’t get all the dependencies from all the components (AntD, Chakra, etc.)?
User’s package.json:
{
"dependencies": {
"<new-rqb-package-name>": "1.0.0"
}
}
User’s QueryComponent.{j|t}sx:
import { BootstrapValueEditor } from '<new-rqb-package-name>'
My first guess is that the libraries my new package would depend on should be devDependencies and peerDependencies, but not regular dependencies (kind of like react and react-dom). Seems like that way, it would fall to the user to install any dependencies for their particular component. But wouldn’t that make a message show up when running npm i or yarn that all the peerDependencies the user doesn’t have installed are "unmet"? If so, is that an acceptable consequence?
Planned package.json for <new-rqb-package-name>:
{
"devDependencies": {
"@chakra-ui/react": "^1.6.5",
"@material-ui/core": "^4.11.2",
"antd": "^4.10.3",
"bootstrap": "^5.0.2",
"react": "^17.0.1",
"react-datepicker": "^4.2.1",
"react-dom": "^17.0.1"
},
"peerDependencies": {
"@chakra-ui/react": "^1.6.5",
"@material-ui/core": "^4.11.2",
"antd": "^4.10.3",
"bootstrap": "^5.0.2",
"react": ">=16.8.0",
"react-datepicker": "^4.2.1",
"react-dom": ">=16.8.0"
}
}