We are using Storybook as a place to deploy and update Recharts documentation - Storybook link.

There is also API documentation available on https://recharts.org/en-US/api, and examples on https://recharts.org/en-US/examples.

The https://github.com/recharts/recharts/issues tab also has a large amount of answered (and unanswered) questions, so you may find inspiration there too.

• d3 upgraded their libraries to be ESM only - this means that any consumer of recharts that upgraded to these patch versions of recharts that used jest or next in their projects also broke as those libraries don't support ESM. We reverted this change in 2.1.15+ due to breaking our consumers.

• Due to reverting the above, we have been on d3-color@2 which includes a ReDos security vulnerability - issue link
• A non-breaking change is being worked on by replacing d3 libraries with victory-vendor/d3-*. Please see this blogpost from victory about them facing this issue and open sources a cjs solution to the problem.
  • victory-vendor takes some select d3 libraries at their latest -> converts them from ESM to CJS -> then adds them back to npm. This is what we are using to prevent breaking our consumers.
• PR for vulnerability fix

• recharts is still very much built on d3 libraries. Please see the two questions above this one. We had to be able to upgrade d3 to avoid security vulnerabilities without breaking our consumers.
• victory-vendor is a commonjs proxy to d3@latest published by the victory team. This allowed us to upgrade d3 without breaking those using jest or next.
• what is next? Recharts must monitor victory-vendor as well as the d3 libraries. Recharts (and the ecosystem) may get to a point where we will have to require support for ESM. In that case we will use d3@latest and release a new major version.

• Yes.

• Recharts maintainers are volunteers and are contributing their own time and effort. We ask that you please be mindful of that while we try to solve some of the pressing issues in the library.