ant-design/ant-design-charts: one React API over four different engines

Four engines behind one import statement

The package description names the scope precisely: plot, graph and map, and the dependency list tells you how that is achieved. The library is based on G2, G6, X6 and L7, which are four separate rendering engines from the same AntV family covering statistical plots, graph visualisation, diagram editing and map rendering. So @ant-design/charts is not an engine, it is a facade over four, and the practical consequence is that the engine is chosen for you by which component you import. That is a good design when your application has all four kinds of visualisation, because one config vocabulary and one set of docs beat four. It is a liability when it does not, because the installation cost of the facade is the sum of its parts. The README never states which component maps to which engine, and there is no table in the documentation excerpt that says that a graph component and a plot component interpret a shared prop name differently. That is the single most useful piece of information a reader of this README does not get, and it is the first thing to look for on the documentation site before you design an API around it.

A chart is two field names, and the escape hatch is undocumented

The usage example is short enough to be the whole mental model. You build a data array of objects, pass it as a prop, and name the two fields that carry the axes:

const props = {
  data,
  xField: 'year',
  yField: 'value',
};

return <Line {...props} />

There is no mark, no scale, no axis configuration in the example. You are describing which columns of your data are which, and the library decides what a Line is. That is a grammar-of-graphics approach rather than an imperative chart builder, and it is why a chart fits in three props. It also fixes where the difficulty goes. Everything the example does not show is resolved by inference, and the day you need a second series, a stacked bar, a log scale or a custom tooltip you discover the full configuration surface, which lives on the documentation site rather than in the README. The harder case is when the declarative layer cannot express what you want at all. The usual escape is to drop to the underlying engine and configure it directly, which is a reasonable thing to do and completely undocumented here. Nobody reading this repository learns whether the escape hatch is supported, stable, or a rewrite of your component.

Installing it, and running the site locally

For use, the install is one line:

npm install @ant-design/charts

For working on the library, the README gives four commands, and they reveal that this is a pnpm workspace rather than a single package:

$ git clone [email protected]:ant-design/ant-design-charts.git
$ cd ant-design-charts
$ pnpm install
$ pnpm build:lib & pnpm start

The last line matters. pnpm start is defined as building the libraries and then starting the site filtered to the site directory, so a working documentation site depends on every package under packages/ having been built first. Running the two with an ampersand, as the README does, is a shortcut that assumes the build and the site start can overlap. The workspace layout is also visible in the two dev scripts, dev:graphs and dev:plots, which change into packages/graphs and packages/plots respectively. So the monorepo is split along the same lines as the public API, plots and graphs, which is the right cut for a facade and means a change to one family does not have to touch the other.

Changesets, three publish paths, and a root package nobody installs

The release story is the most disciplined part of this repository, and the scripts in the root package.json describe it end to end. Versioning runs through changesets: ci:version calls pnpm changeset version and add:changelog calls pnpm changeset, so changelog entries are authored as changesets rather than edited by hand, and there is a CHANGELOG.md in the tree to receive them. Publishing has three separate paths. release builds everything and then runs pnpm changeset publish, release:alpha does the same with the alpha tag, and release:beta uses the beta tag. On top of that sits a plain publish script that walks the workspace, excludes the site directory, restricts itself to the master branch, and targets the npm registry by URL. Note that the root package.json is named charts and marked private, so the thing you install and the thing you clone are different artifacts. The publish filter excluding the site tells you the documentation site is not shipped, and the branch restriction means release is a deliberate act on master rather than something a tag triggers.

Two bundlers, two test runners, and a profile script for the size claim

The feature list calls the library pretty and lightweight, and the toolchain is where you can check the second half of that. There is a mako.config.json in the root, and the profile script runs webpack with a production mode and the profile flag, writing stats.json. So two bundlers are configured in one repository, which is what a build in transition looks like from the outside, and the existence of a bundle profiling script means the size question is at least instrumented rather than asserted. The same is true of testing. Unit tests are Jest, run with the swc transform, and they are executed per package by a recursive script filtered to packages/*. End-to-end tests are Playwright, run from the root through a dedicated playwright.config.ts. Having a browser-level suite in a chart library is not incidental: chart output is a rendering result, and asserting on it in a DOM stub is close to meaningless, so the e2e layer is doing the verification the unit layer structurally cannot. The residue worth noting is the presence of a .babelrc and of Enzyme type definitions alongside the swc and Playwright setup, which suggests tools that have been used and not fully removed.

The release gap is the argument against it

Here are the dates, because they decide the adoption question for a library like this one. The newest release is 2.6.7 from 2025-12-23, preceded by 2.6.6 in October 2025 and 2.6.5 in September 2025, so during 2025 the project shipped three patch releases at a normal pace. The last push to the repository was 2026-03-26, and the repository is not archived. So there are three months of commits after the newest tag, and roughly nine months between that tag and today. For an ordinary application library, a nine-month-old patch release is unremarkable. For a facade over four engines it is the central risk, because the value proposition is not the React wrapper, it is keeping four moving upstream APIs behind one surface. When G2 or G6 changes shape, the wrapper is what absorbs that, and a wrapper that has not published since December 2025 may be absorbing changes without shipping them. That is a hypothesis rather than a documented state, and the way to settle it is to read the changelog and compare it against the four upstream repositories. A single family requirement, or a team that can track the engines itself, changes the answer.

The contribution path is the other asymmetry

The repository carries CONTRIBUTING.zh-CN.md and nothing else in that slot, so the contribution guide is Chinese only. The README itself says contributions are welcome and asks people to look at the issues first, and the documentation site serves English paths, so the outward-facing surface is bilingual while the inward-facing process is not. The listed contact is a DingTalk group with a number in the README, which is a workable channel if you read Chinese and an unhelpful one if you do not. Set against that, the engineering surface is unusually complete: a lint configuration for both JavaScript and styles, editor and prettier configuration, a changeset workflow, per-package tests, browser-level e2e and a bundle profile. So the practical judgement is that outside contributions are structurally supported and socially awkward, which usually means low-quality patches rather than no patches. If you are evaluating this for a team with non-Chinese-speaking contributors, that is a real cost to price, and it is the kind of thing that shows up in the issue tracker six months later rather than during evaluation.

Editorial conclusion

Adopt @ant-design/charts when you need more than one chart family in the same application and you want a single config vocabulary across them, because that is the whole value and the xField and yField surface is as small as it gets. Do not adopt it for a single line chart, since the facade sits on top of four engines and you would be installing all of them to use one. Verify two things before you commit. Check the release history against the last push, 2026-03-26, with the newest tag at 2.6.7 from 2025-12-23, because a wrapper earns its keep by tracking upstream and that gap is the one number that argues against it. And confirm the English contribution path, since CONTRIBUTING.zh-CN.md is the only guide in the repository and the contact channel is a DingTalk group. If the answers are acceptable, install with npm install @ant-design/charts and measure the bundle claim yourself with pnpm profile.

Frequently asked questions

Official sources

1. ant-design/ant-design-charts on GitHub
2. License: MIT
3. Project website
4. README
5. Releases