Carbon Charts ships 26 chart types across five JavaScript frameworks

One D3 core with five framework wrappers published from one repo

Carbon Charts is a charting library built on D3 and TypeScript, published under the Apache-2.0 licence. The README describes it as a component library of 26 charts for vanilla JavaScript, Svelte, React, Vue.js and Angular, and the repository layout matches: packages/core holds the vanilla implementation and there are separate packages for svelte, react, vue and angular.

That structure is the core design decision. A D3 chart is fundamentally imperative: you build scales, axes and elements yourself, which produces a lot of code and a lot of room for inconsistency between charts. Carbon Charts takes that machinery and wraps it in components per framework, so the same chart behaves the same way in a React app and in a Vue app, and the styling follows the Carbon design system rather than whatever the hosting application's CSS happens to do.

The consequence for an adopter is that the framework packages are not optional extras. If your organisation runs a mix of React and Vue, the value of the library is precisely that both consume the same underlying chart definitions. If you run one framework, you are paying for a D3 abstraction that could have been hand rolled, and you should weigh that against how much configuration the library saves you.

The project documentation at charts.carbondesignsystem.com includes StackBlitz examples of each chart type for the supported frameworks, which is the fastest way to judge whether the configuration model fits your data.

The support table is blunt: 1.x yes, 0.x end of life

Carbon Charts publishes a supported versions table with two rows. The 1.x line is marked as supported, and the 0.x line is marked as end of life. That is a short but important piece of information, because a charting library that silently drops a major version leaves you on an API that receives no fixes.

The README points to a release schedule document in the .github directory for full details on what release phase versions are in and the level of support provided for each. The existence of that document, plus the semantic-release automation the project uses to version releases within the Semantic Versioning guidelines, means the project has a defined policy rather than an informal one.

The version numbers themselves show how the project operates. Recent releases are v1.27.21 on 2026-10-05, v1.27.20 on 2026-09-16 and v1.27.19 on 2026-09-08, so the patch counter is climbing steadily while the major version has stayed at 1 for a long time. That is a good sign for a library embedded in many products, since a stable major line means you can upgrade within 1.x without a migration project.

The repository is not archived, and the last push was on 2026-10-05, the same day as the newest release. Change logs for each release are published on the repository releases page, and the CHANGELOG.md file is at the root.

Lerna, Yarn 4, Nx and a Node 22.18 floor shape the contributor workflow

The root package.json names the repository @carbon/charts-monorepo and marks it private, with the workspaces set to packages/*. The build is delegated to Lerna across those packages:

"build": "lerna run --stream build",
"lint": "lerna run lint",
"format": "lerna run format",
"test": "lerna run test"

Two package manager details matter for anyone cloning the repository. The packageManager field pins [email protected], and the engines field requires Node ^22.18.0. Yarn 4 is the modern release line with the.yarn/ directory and.yarnrc.yml at the root, and the lockfile is a yarn.lock.

The repository also carries nx.json alongside lerna.json.

Linting and formatting are separate concerns. The devDependencies include ESLint 9 with a flat eslint.config.mjs at the root, Prettier 3 with prettier-config-carbon, and plugin sets for React, Vue, Svelte and jsdoc, so each framework package is linted with the rules that apply to it. Commit messages are checked with commitlint and the conventional-commits config, and lint-staged with a lint-staged.config.mjs runs on staged changes, wired in through husky and a.husky/ directory. The prepare script is husky || true, so a failed hook install does not break installation.

Playwright drives the DOM test suites, with a rebase variant

Beyond unit tests, the repository has a browser test story, and it is the more interesting one for a charting library. A chart library that is only tested in jsdom proves very little, because SVG layout, text measurement and event handling all depend on a real rendering engine.

The root package.json defines the DOM test scripts:

"test:dom": "npx playwright install && lerna run build --scope @carbon/charts && lerna run test:dom --parallel",
"test:dom:rebase": "npx playwright install && lerna run build --scope @carbon/charts && lerna run test:dom:rebase --parallel"

The pattern is the same in both: install the Playwright browsers, build the core @carbon/charts package, then run the per-package DOM tests in parallel. Building the core first matters because the framework packages consume it.

The rebase variant is the part with a story behind it. A rebased test suite implies comparing rendered output against an updated baseline, which is the standard approach for visual or structural snapshot testing but also the standard source of churn: a change to the chart's DOM structure breaks many baselines at once. Having a separate command for that workflow, rather than folding it into the normal test run, keeps the ordinary path fast and readable.

The tests directory and the scripts directory at the root hold the supporting infrastructure, and the .github workflows are where this all runs in CI.

Installation goes through npm packages, one per framework

The README does not give a command line install snippet, so the practical route is the published packages on npm. The primary one is @carbon/charts, which the README links to on npm, and the framework packages live alongside it in the same monorepo: the vanilla implementation in packages/core, and separate packages for Svelte, React, Vue and Angular.

The README also states that the library is published under semantic versioning, with the releases automated by the semantic-release library. For a team consuming several of these packages, that means the version numbers of the core and the framework wrappers are related but not identical, and a dependency update can pull in a new core without a new wrapper.

Two pieces of infrastructure sit alongside the library itself. There is a netlify.toml, which is what publishes the documentation site, and an assets/ directory holding the images used in the README, including the hero image and a dashboard screenshot. The .whitesource directory points at a dependency scanning configuration, and there is a SECURITY.md at the root, which tells you the project has a documented process for reporting vulnerabilities rather than only an issue tracker.

The CODEOWNERS file and the .all-contributorsrc are the other two markers of a project with an active process around contributions, and the README lists a core team with a division of labour across code, documentation, examples, infrastructure, design, project management and research.

The alternative is per-framework chart code with no shared design decisions

It is worth naming what this replaces, because the comparison is not chart library against chart library so much as shared component against per-project code.

A team that does not adopt Carbon Charts has options. Charting libraries tend to be tied to a single framework and to their own visual language. That means a separate integration per stack, and none of them give you the same chart in five frameworks from one source.

The real alternative to Carbon Charts is usually to write your own chart components once per framework, or to accept a different visual language for charts than for the rest of the product. That is the trade the library makes explicit: you accept a fixed set of 26 chart types and Carbon's design decisions in exchange for consistency and a single source of truth across frameworks.

The 26 number is the boundary. If a requirement needs a chart type outside that set, this is the wrong library, and the project does not present Carbon Charts as a general purpose plotting library.

Editorial conclusion

Adopt Carbon Charts if your design system already uses IBM Carbon and you want its chart styling and accessibility decisions applied consistently across React, Vue, Svelte, Angular and plain JavaScript rather than maintaining chart code per stack. Do not adopt it if you are on the 0.x line, which the support table marks as end of life, or if you need chart types outside the 26 the library covers. Before you install, check that your build environment runs Node ^22.18.0, note that the framework packages ship separately from the core package, and plan to read the release schedule document, since the project publishes per-package versions and marks 0.x as EOL.

Frequently asked questions

Official sources

1. carbon-design-system/carbon-charts on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases