recharts' newest tags are canaries, its UMD example pins React 18, and every install needs a matched react-is

The three newest releases are all canary builds of the same unreleased minor

The release list is worth reading carefully, because none of the three newest tags is a stable release. They are v3.11.0-canary.7 on 2026-10-24, v3.11.0-canary.8 on 2026-10-29, and v3.11.0-canary.9 on 2026-11-03. So the project is publishing canaries of 3.11.0 while the stable line users install is something earlier, and the newest thing in the repository is not what lands on npm under the latest tag. The manifest agrees with the canary rather than with a stable number, since its version field reads 3.11.0-canary.9, the same string as the newest tag. That is consistent internally and confusing externally: if you read the repository's version to find out what you are running, and then install the stable package, the two numbers do not match and nothing explains the gap. The three canaries landed five days apart.

The documented UMD example pins react, react-dom, and react-is at version 18

Three installation routes are offered and one of them has drifted. npm is called the easiest and fastest way to get started and the recommended method for single-page applications, pairing nicely with a CommonJS bundler such as Webpack. Deno is described as a drop-in replacement for npm, so it installs the same way. The UMD build is the odd one out, and the four script tags it asks for are:

<script src="https://unpkg.com/react@18/umd/react.production.min.js"></script>
<script src="https://unpkg.com/react-dom@18/umd/react-dom.production.min.js"></script>
<script src="https://unpkg.com/react-is@18/umd/react-is.production.min.js"></script>
<script src="https://unpkg.com/recharts/umd/Recharts.js"></script>

All three React packages are pinned at major version 18, while the library itself is left unversioned so it resolves to the newest published build. After loading, the library is on window.Recharts. So the script-tag path pairs an old React with a current library, and anyone using it has to edit those URLs by hand to move forward. The two module paths do not have this problem because they resolve React from your own dependency tree.

Every install route requires a second package whose version must match your React

The install line is two packages, not one, and there is a constraint attached:

# latest stable
$ npm install recharts react-is

The README then states that react-is needs to match the version of your installed react package. The Deno route repeats the same pair. The consequence is that this library adds a piece of ongoing maintenance to your dependency list: a React major bump means a react-is bump in the same commit. Nothing in the README automates that pairing or warns you at build time, so it stays a manual obligation.

There is no series object; each data key becomes its own sibling component

The composition model is the thing to understand before writing anything. The example is five sibling components inside a chart:

<LineChart width={400} height={400} data={data}>
  <XAxis dataKey="name" />
  <Tooltip />
  <CartesianGrid stroke="#f5f5f5" />
  <Line type="monotone" dataKey="uv" stroke="#ff7300" />
  <Line type="monotone" dataKey="pv" stroke="#387908" />
</LineChart>

Each of those is an independent React component, and the README names the clear separation and composition of components as one of the project's principles. So a chart is assembled from parts rather than configured from a series array, and adding a third line means adding a third child. Two things are worth noticing. The axes and the grid are siblings of the data, not configuration on it, so what a series renders is decided by the tree around it. And the minimal example hardcodes a 400 by 400 size, so responsiveness is something the example deliberately leaves out rather than something you inherit.

main and release hold different code, and the published storybook follows release

The documentation section states a branch arrangement that changes how you read examples. It says all development is done on the main branch, and that the current latest release and storybook documentation reflect what is on the release branch. The default branch is main, so a clone lands you on the code that is not what the hosted documentation is showing. The practical consequence is a specific and recurring confusion. A chart that does not behave as the example on the storybook site may already be fixed on main, or the example may show a prop that has not landed in the stable release, and there is no version marker on the example itself to tell you which. If you are reproducing a documented example, read the release branch rather than main, and if you are reporting a bug, say which branch you saw it on. The wiki is offered as a third place for information, alongside the docs site and the storybook.

Three published entry points, and the build verifies its own output

The manifest declares three ways in, which is why bundler configuration matters. The CommonJS entry is at lib/index.js, the module and jsnext:main fields both point at es6/index.js, and the UMD build is a separate tree, with type declarations in a fourth. Alongside that, sideEffects is set to false, which is the claim that permits bundlers to drop unused imports. That claim is worth taking seriously rather than skimming: an import that does have a side effect will be removed, so anything relying on import-for-effect will not survive tree shaking. The build script is equally explicit, running the types build, the CommonJS build, the ES build, and the UMD build in sequence, and then running a step named test-build-output. The CommonJS and ES trees are produced by separate Babel invocations with different environment values after the destination is deleted, so the two outputs are genuinely distinct artifacts rather than one transformed twice.

Bundle size is budgeted, mutations are tested, and renders are diffed as images

The repository root shows a level of quality instrumentation that most chart libraries do not carry, and each piece answers a different question. A bundlewatch configuration puts a budget on shipped size, which is the direct counterweight to a library that adds a D3 dependency. A Stryker configuration exists alongside a Vitest mutation-testing config, and mutation testing answers whether your tests would notice a bug at all by breaking the code on purpose and requiring the suite to fail. Visual regression lives in its own directory with a Playwright container, and the compose file for it publishes a report server on port 9323 that bind-mounts the source and the site so the report reflects local changes. Chromatic is credited in the README for the visual testing platform that catches UI regressions. The practical consequence is a repository you should trust on rendering, and one where a contribution is expected to keep all of those suites green.

Editorial conclusion

Recharts suits a team that wants charts composed from React components with SVG output and no canvas, and that is ready to keep a second package version-matched to React. It is a poor fit if you need a stable published version you can name, since the newest tags are canary builds of an unreleased minor, and a poor fit if you load the library from a script tag, since the documented UMD example pins React 18. Before you commit, check which version npm actually resolves against the canary tags, keep react-is on the same version as react, and read the release branch notes rather than main if you are reproducing a documented example.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. recharts/recharts on GitHub
5. Releases