In order to support Victory and Apache ECharts, I'd like make Victory a peer dependency.
That way, users can choose which library they want to use.
If devs don't want Sankey, they can omit the package from the install or vice versa.
ConsoleDot has already done this with their @redhat-cloud-services packages.
For example, react-core, react-icons, and react-table are peer dependencies for frontend-components.
I would also like our imports to be:
import { Chart } from '@patternfly/react-charts/victory';import { Sankey } from '@patternfly/react-charts/echarts';
We could introduce this change separately, but thinking v6 would be a better time to make this type of change.
Peer dependencies would make it a lot easier to introduce new features, regardless of the library we choose.
And probably less disruptive if we do it now
In order to support Victory and Apache ECharts, I'd like make Victory a peer dependency. That way, users can choose which library they want to use.
If devs don't want Sankey, they can omit the package from the install or vice versa. ConsoleDot has already done this with their @redhat-cloud-services packages. For example, react-core, react-icons, and react-table are peer dependencies for frontend-components.
I would also like our imports to be:
import { Chart } from '@patternfly/react-charts/victory';import { Sankey } from '@patternfly/react-charts/echarts';We could introduce this change separately, but thinking v6 would be a better time to make this type of change. Peer dependencies would make it a lot easier to introduce new features, regardless of the library we choose. And probably less disruptive if we do it now