Frappe Charts is zero dependency SVG, and its README recommends a 2021 build

It exists because c3.js was the wrong shape for an ERP screen

The motivation section is the most informative part of the README, and it names the alternative directly. ERPNext needed a simple sales history graph for its user company master so users could track sales. The team was using c3.js for reports, and the library did not align well with the product's classic design. Existing JavaScript libraries were described as either too complex or rigid in structure and behaviour, so the response was to write a library focused on translating value pairs into relative shapes or positions.

That origin explains the design constraint that runs through everything else. A company master screen needs a few legible charts, not a reporting suite. The library is scoped to that job, and the GitHub-inspired look in the title follows from charts being borrowed from the design language people already read every day.

The dependency claim is the other headline. The package lists no `dependencies` at all in its package.json, only devDependencies. Every runtime dependency is absent, which for a charting library is unusual: most bring in a rendering engine or a utility belt.

The repository shows what that zero means in practice. The build is rollup with a plugin set covering babel, commonjs, eslint, postcss, scss, terser and bundle-size. There is a `.travis.yml` and a Makefile with build, clean, test and coveralls targets. All of that is build time only.

The author is credited in the package metadata as Prateeksha Singh, and the blog post linked at the end of the README is the longer account of why the project was started.

labels and datasets is the entire data model

The README example uses a `labels` array of strings and a `datasets` array of objects, each with a `name`, a `chartType` and a `values` array:

const data = {
    labels: ["12am-3am", "3am-6pm", "6am-9am", "9am-12am",
        "12pm-3pm", "3pm-6pm", "6pm-9pm", "9am-12am"
    ],
    datasets: [
        {
            name: "Some Data", chartType: "bar",
            values: [25, 40, 30, 35, 8, 52, 17, -4]
        },
        {
            name: "Another Set", chartType: "line",
            values: [25, 50, -10, 15, 18, 32, 27, 14]
        }
    ]
}

The `chartType` sits on the dataset rather than the chart, which is what makes a mixed chart possible: in one example one dataset is a bar series and the other a line series, rendered under a single `axis-mixed` chart type.

The constructor takes a selector or a DOM element plus options:

const chart = new frappe.Chart("#chart", {
    title: "My Awesome Chart",
    data: data,
    type: 'axis-mixed',
    height: 250,
    colors: ['#7cd6fd', '#743ee2']
})

Note the negative values in the datasets, both a `-4` and a `-10`. A chart that has to render data below zero has to make a decision about the baseline, and the fact that the README's own demo includes negatives suggests it handles them.

The `type` option is documented as accepting `axis-mixed`, `bar`, `line`, `scatter`, `pie` and `percentage` in the constructor comment, while the key features list names a wider set including Axis Charts, Area and Trends, Heatmap and Mixed Axis. The constructor list is the shorter one, and the README does not reconcile them, so treat the feature list as the broader catalogue and the constructor as the confirmed set.

Three ways to load it, and which one you actually want

The package ships several builds and the README shows how to reach each.

From a bundler, the install is one command:

npm install frappe-charts

then an ESM import, with an optional deeper import for the ESM bundle and a separate import for stylesheet:

import { Chart } from 'frappe-charts'
// or esm import
import { Chart } from 'frappe-charts/dist/frappe-charts.esm.js'
// import css
import 'frappe-charts/dist/frappe-charts.min.css'

From a plain HTML page, a UMD script tag, and the version in that example is pinned:

<script src="https://unpkg.com/[email protected]/dist/frappe-charts.min.umd.js"></script>

That tag is instructive in an awkward way. It references `[email protected]`, while the package.json version is `v1.6.3`, so the README's copy and paste snippet is one patch behind the current tag. The unpkg path is the kind of thing that survives in a README for years without being revisited.

Note also the naming collision in the constructor examples. With the UMD script loaded globally you construct `new frappe.Chart(...)`, while with the ESM import you use `new Chart()`. The README flags this in a comment on the constructor, and it is the first thing to get wrong when copying an example.

The package metadata describes the build matrix: `type` is module, `main` and `module` both point at the ESM build, `browser` at the UMD build, `common` at a CJS build, and `unnpkg` at the UMD build again. The `files` field publishes only `src` and `dist`, so the raw source is available for patching.

One CSS file is imported separately, which means the library ships no styles by default into your build unless you take that import.

Dynamic data is the feature ERPNext needed

The key features list describes data handling as: add, remove, or update individual data points in place, or refresh the entire dataset to reflect changes.

This is the part that separates a static chart renderer from a component in an application. An ERP screen showing sales history is not a report you generate once; it is a view that updates when a sale is recorded, when a filter changes, or when a user drills into a period. A library that only exposes render from data forces the whole model to be thrown away and rebuilt on each change, which loses animation, loses any state you had, and is slower on exactly the screens where responsiveness is the point.

The other capability worth calling out is annotation. The README states charts can be annotated with x and y markers and regions, plus tooltips. Regions in particular are what turn a line into something you can reason about, since a shaded span tells you an incident, a campaign or a release window happened there. For the sales history use case that was the original motivation, marking a period is more useful than a tooltip on every point.

Configurable options are listed as colours, animations and custom titles, with height as a plain number, which is what the constructor example shows.

What is not described is scale formatting, tick configuration, axis label rotation, logarithmic scales, stacked totals or axis titles. That absence is the clearest signal of the library's scope: it draws marks and positions them, and hands formatting decisions to you.

The build system and the release gap

Two facts about the repository shape the adoption decision more than the feature list does.

First, the release gap. The most recent published tag is v1.6.3, dated 2022-04-27. Before it, v1.6.1 shipped on 2021-04-18 and v1.6.0 on 2021-04-11, so two patch-level releases landed within a week of each other more than five years ago. Yet the last push to the repository was on 2026-10-15, the day before this article was written. The repository is being actively worked while the published package is years behind.

That gap has a concrete consequence: installing `frappe-charts` from npm gets you v1.6.3, which is not what is in master. Anyone who wants current behaviour must build from source, and anyone who wants a stable dependency is depending on a 2022 artefact.

Second, the test story. The npm `test` script is literally `echo "Error: no test specified" && exit 1`, which is the npm init default and is never overridden. The Makefile has a `test` target that runs mocha through nyc over `$(SRCDIR)/js/**/test/*.test.js`, and a `coveralls` target, so a test setup existed at some point under the Makefile path. The Makefile also installs yarn globally if it is missing, which means `make build` mutates your global npm prefix.

What this means practically: do not expect a published library with a documented test suite at the version npm serves you. That is not disqualifying for a small internal UI component, and it is disqualifying if you need to upgrade with confidence in a large codebase.

Licence is MIT, the repo is not archived, and documentation lives at frappe.io/charts/docs with a demo gallery at frappe.io/charts and a CodeSandbox for editing.

Editorial conclusion

Adopt Frappe Charts if you are building an interface where a charting library's weight is the binding constraint, such as an ERP screen that needs a sales history graph, and your chart types are bar, line, pie, percentage, heatmap or a mix of those. Do not adopt it if you need axes formatting control, deep configuration or a maintained release cadence, since the newest published tag is v1.6.3 from 2022 while the repository itself was pushed to on 2026-10-15. Verify first that the dist build in the published package matches the source in master, since the two have moved at different rates.

Frequently asked questions

Official sources

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