c3js/c3: D3 power with a declarative API, and a build pipeline that outgrew its last release

The README sells documentation, not the library

This README is unusually short, and it is short on purpose. There is a one-line description, c3 is a D3-based reusable chart library that enables deeper integration of charts into web applications, a link to c3js.org, and then four links out: Getting Started, Examples, the Full API Reference, and a pointer to the samples directory inside the repository.

Everything else on the page is process rather than product. There is a Google Group for general discussion, a Gitter chat badge, and then a substantial section on using the issue queue.

That section is worth reading because it tells you how the project expects to be used. The queue is for reporting defects and problems, in addition to feature requests and ideas, and it is explicitly not a catch-all support forum. General support goes to the Google Group, and the README goes further: all questions involving the interplay between C3.js and any other library, AngularJS named as the example, should be posted there first.

Before filing anything, there is a four-step checklist. Search existing issues for duplicates. Search the Google Group to see if it was addressed already. Create a JSFiddle or Plunkr that isolates the problem, with a warning not to include unnecessary dependencies, and another warning that custom CSS can modify C3.js output. Then post with a descriptive title, the version of C3 or the commit hash if cloning, and relevant platform, browser and OS information.

The pull request section adds two rules: post an issue first to see whether a change is desirable, and do not bump the version number unless asked, with test cases required for new features and commits squashed.

package.json tells you more than the README does

The real architecture of this project is in its manifest, and it describes a modern build chain that the README never mentions.

"serve-static": "static -p 8080 htdocs/",
"lint": "jshint --reporter=node_modules/jshint-stylish src/ spec/",
"type": "tsc --noEmit",
"build": "run-s build:js build:css",
"build:js": "run-s build:js:rollup build:js:uglify",
"build:css": "run-s build:css:sass build:css:min"

Several things follow. The library is written in TypeScript, since both the `type` script running `tsc --noEmit` and the `fmt` script formatting `src/**/*.ts` point there, and there is a `tsconfig.json` at the root. JavaScript bundling goes through rollup with a `rollup.config.js`, minification through uglifyjs, styles through sass compiled from `src/scss/main.scss`, and CSS minification through cleancss. The test target is `run-s build lint karma`, so a full test run builds the bundle, lints with jshint over `src/` and `spec/`, then runs karma against `karma.conf.js`.

The `dist` script reveals where output goes. Built artifacts are copied from `htdocs/{css,js}/` into the repository root and into `docs/`, which is why `c3.js`, `c3.min.js`, `c3.esm.js`, `c3.css` and `c3.min.css` are all committed at the top level. The `files` array in the manifest confirms which of those ship in the npm package.

There is also Ruby in the pipeline. `docs` runs `bundle exec middleman`, and the tree has a `Gemfile`, a `Gemfile.lock`, and a `config.rb`, so the documentation site is a Middleman app rather than something generated by the JavaScript toolchain.

Three distribution formats, one version, no release since 2020

The `main` field is `c3.js`, and the `files` array lists six entries: the unminified and minified JavaScript, an ES module build at `c3.esm.js`, the unminified and minified CSS, and the `src` directory itself. Shipping sources alongside the bundles is generous and unusual, and it makes the library readable once installed.

The version is 0.7.20, matching the most recent published release tag, v0.7.20, dated 2020-08-08. Before that, v0.7.18 on 2020-06-16 and v0.7.17 on 2020-06-15.

So the npm artifact has not changed in more than six years, while the repository has. The last push on `main` was 2026-09-14, and the project is not archived, which means the situation is specific rather than general: the code continues to move, the published version does not. That distinction decides whether you should depend on the tarball or on the branch, and it is worth being deliberate about.

The tree also carries `bower.json` and `component.json`, two package manifests from package managers that predate npm's current position. Their presence next to `rollup.config.js` and `tsconfig.json` is a fair signal of how far the project has come and how much of its history is still in the working tree.

On scale: 9,351 stars, 1,360 forks, and 771 open issues. That last number is the one to sit with. For a library of this age with a small number of tagged releases, a queue that size is the normal consequence of depending on a project whose npm version stopped moving.

D3 v5 is the dependency that defines the ceiling

The Dependency section of the README is two lines long and contains one entry: D3.js at `^5.0.0`. The whole positioning of the library follows from that single constraint.

The stated purpose is deeper integration of charts into web applications, and the way c3 achieves it is by exposing configuration rather than requiring you to manipulate a selection. You describe a chart in terms of its columns, types, axes and colors, and the library handles the underlying D3 work including transitions and interactions. That is a real abstraction, and it is the reason to use c3 instead of writing D3 directly.

But it is built on an old major version of D3. D3 went through breaking changes in v6 and v7, and c3's caret range pins it to the v5 line. Practically, that means a project already on a current D3 cannot also load c3 without two copies of D3 in the page, which is the kind of conflict that produces subtle bugs in tooltips and event handling.

The `spec/` directory and `karma.conf.js` indicate a browser test setup, and the README's insistence on a minimal JSFiddle before filing an issue is consistent with a library whose correctness depends on getting the D3 interaction model right. Whether the current branch has moved past the v5 pin is exactly the kind of question the source answers and the README does not, since the dependency section still shows the original declaration.

Running the samples is one npm script

The repository's own samples live in `htdocs/samples`, and the README gives you exactly one command to look at them.

$ npm run serve-static

That script is `static -p 8080 htdocs/`, so it serves the `htdocs` directory on port 8080 with no build step required first. That is a nicer developer experience than it sounds, since a chart library's real documentation is a gallery of configurations you can read and copy.

There is also `npm start`, which runs `serve-static` and `watch` together. The watch script uses nodemon against `src`, triggering a rollup rebuild on JavaScript changes and a sass rebuild on stylesheet changes, with separate `watch:js` and `watch:css` variants for narrower loops.

The rest of the tree explains what else is in the repo. `design/` is there, which for a chart library usually means design assets or explorations. `data/` holds data for examples. `extensions/` is a separate directory, worth checking if you are looking for something beyond the core chart types. `spec/` is the test suite. `docs/` receives built assets on every dist run, and `.bmp.yml`, `codecov.yml`, `.prettierrc.json`, `.jshintrc` and `.editorconfig` cover CI, coverage and formatting conventions.

The README also names a Playground fiddle to fork, hosted on JSFiddle at a specific revision, which is a more reliable starting point than a blank editor when you are reproducing something.

Where a new user actually lands

The documentation is split across two places and they are not equally current. c3js.org carries the Getting Started guide, the Examples gallery and the Full API Reference. The repository carries `htdocs/samples`, plus a Middleman site under `docs/` built by `bundle exec middleman` and published to gh-pages with a skip-ci commit marker.

Two different doc systems for one library is a maintenance smell, and it is a fair proxy for the overall state: the tooling has been kept current while the documentation structure has not been consolidated.

The honest comparison is with what you would otherwise reach for. If you want full control over every mark and transition, D3 directly is the better answer and there is no abstraction tax. If you want a line chart with a configurable tooltip, an axis with sensible defaults and a transition you did not have to write, c3 gives you that in a fraction of the code. Where c3 stops being attractive is anywhere the pinned D3 version collides with the rest of your stack, or anywhere you need a chart type the configuration does not cover and have to drop down into internals.

For a maintainer looking at the issue queue, the README sets the expectation plainly: 771 open issues, a small number of tagged releases, and a project whose npm version has been static since 2020 while the branch keeps moving. The most useful thing a reader can take from the repository is the build manifest and the source tree, since those show what the library actually is today rather than what was published to npm three years into a six-year silence.

Editorial conclusion

c3 solves a specific problem well: you know the chart type you want and you do not want to write the axis, scale and transition code. For that case its declarative configuration is a real saving, and the transition and interaction defaults are the part you would spend the most time reproducing yourself. The counterweight is equally concrete. The published version is 0.7.20 from August 2020, D3 is pinned at `^5.0.0` while newer major versions exist, and the repository still carries `bower.json` and `component.json` next to a modern rollup and TypeScript setup. Start by reading `package.json` for the real build graph, then `src/` to see whether the current branch is something you want to depend on rather than the npm tarball, and check the issue queue size before assuming a fix will arrive.

Frequently asked questions

Official sources

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