fl_chart: six chart types, one data shape, and 406 open issues

One library, six chart families

fl_chart is a Dart package that renders charts in Flutter, published to pub.dev and hosted at `github.com/imaNNeo/fl_chart`. The description names the set explicitly: Line, Bar, Pie, Scatter, Radar and Candlestick. Note that the README's own overview paragraph lists only five of them, stopping at Radar, while the chart type table below it includes a Candlestick column with its own documentation link. The topic tags on the repository include candlestick variants, and release 1.2.0 touches `CandlestickTouchData` alongside the other five, so Candlestick is real and supported even though the summary sentence is out of date. That is a small conflict inside the README itself, and the table and the changelog are the more reliable sources.

The design is worth understanding before you write code. Each chart is a widget that takes a data object, and inside that data object the configuration is split by concern: titles, borders, grid data, touch data, and the chart specific series. Titles carry axis labels, side titles and reserved sizes. Touch data carries the enabled flag, the tooltip builder and the hit test configuration. For Line charts the series is a list of `LineChartBarData`, for Bar charts a list of `BarChartGroupData` containing rods and stacks, for Pie charts a list of `PieChartSectionData`, for Scatter a list of `ScatterDotData`, for Radar a list of `RadarDataSet`, and for Candlestick a list of `CandlestickChartData`. Learning one means learning the vocabulary of the others, which is the main reason teams stay.

The documentation lives in the repository

There is no separate documentation website for the API reference. The project homepage is `flchart.dev`, but the substance is committed to the repository under `repo_files/documentations/`, with one markdown file per chart type: `line_chart.md`, `bar_chart.md`, `pie_chart.md`, `scatter_chart.md`, `radar_chart.md` and `candlestick_chart.md`, plus an `index.md` as the entry point.

Each of those files follows the same shape. A set of animated sample gifs appears at the top, then named source code blocks with anchors the README table links directly to, such as the `#sample-1-source-code` fragments used by every gif in the chart type grid. Configuration reference follows the samples, including per chart sections such as `LineTouchData` read about touch handling, which the release notes link to directly.

This arrangement has a practical consequence. When you search for how to configure something in fl_chart, you are searching a repository, so results come with the version of the code they describe, and the anchors in release notes resolve to a specific line range that moves with history. If you prefer browsing, the demo at `app.flchart.dev` renders the same chart families interactively, with the overview links in the README routing to `#/line`, `#/bar`, `#/pie`, `#/scatter` and `#/radar`. Between the two, you can see a chart, read the code that produced it, and check whether the parameter still exists in the version you depend on.

The example app is a real application

The `example/` directory is not a single screen. It carries `.metadata`, `analysis_options.yaml`, a `Gemfile` and `Gemfile.lock`, `fastlane/`, `devtools_options.yaml`, `assets/`, and platform folders for `android/`, `ios/`, `linux/`, `macos/`, `web/` and `windows/`, with its own `pubspec.yaml` and a `lib/` directory. In other words the repository builds the samples into a full cross platform Flutter application and ships release automation for them.

That has two effects for a user of the library. The samples you read in the documentation are exercised on six platforms rather than one, which is why platform specific rendering bugs tend to get caught. And the source of truth for how a feature is meant to be used lives in `example/lib/`, which is the place to read when a documentation page is thinner than you need.

The remaining top level entries follow the same completeness. `CHANGELOG.md` carries the release history, `CONTRIBUTING.md` the contribution rules, `analysis_options.yaml` the lint configuration, `pub_screenshots/` the images pub.dev displays, `test/` the test suite, and two files that are more unusual: `CLAUDE.md`, presumably agent instructions for automated contributors, and `SOURCES.md`, which lists where the sample designs came from. The README credits the banner designer and a list of designers on Dribbble and UI kits whose work the samples are inspired by.

How the project builds and checks itself

The repository has a Makefile rather than relying on memorised commands, and the file handles Windows separately by swapping the file finder for a `dir /S /B` pipeline that excludes generated mocks. The core targets are short enough to read in one sitting.

flutter analyze
dart format -o none --set-exit-if-changed $$( $(FIND_CMD) )

`analyze` runs the Flutter analyzer, `checkFormat` fails the build if any Dart file under `lib` or `test` is unformatted, `checkstyle` chains both, and `format` rewrites the files in place. Tests run under `flutter test` through the `runTests` target, and `sure` runs tests and then style checks, with the comment in the file telling you to use it before pushing. Coverage goes through `flutter test --coverage`, then `genhtml coverage/lcov.info` and a call into `scripts/makefile_scripts.sh` that opens the generated HTML report, which is why the tree includes both `scripts/` and a `.codecov.yml`.

Code generation is separate from the build. `codeGen` runs `build_runner` with `--delete-conflicting-outputs`, and the mock files in the test suite are the reason. A second target named `buildRunner` still exists and calls the older `flutter packages pub run` form, which is a leftover worth knowing about if you copy targets from the Makefile. There are also two git helper targets: `checkoutToPR` fetches a pull request head as a local branch, and `findVersion` uses `git describe --contains` with a `sed` that strips everything after a `~` so pre-release tags report cleanly.

What the last three releases changed

Three releases are visible in the collected history, and together they describe a project in maintenance mode rather than a growing one.

Version 1.1.0, published 2025-08-31, is the feature release. It added a `gradient` property to `BarChartRodStackItem` so stacked segments can render a gradient as well as a solid colour, a `sideTitleAlignment` property on `AxisTitles` that lets you place side titles inside the plot area, a `gradientArea` property on `LineChartBarData` to control where a fill gradient applies, and `label` and `labelStyle` on `BarChartRodStackItem` so each stacked segment can carry its own text. It also carried a breaking change admitted in the notes: `borderSide` in the `BarChartRodStackItem` constructor became a named parameter instead of an optional positional one, which the maintainers apologise for shipping in a minor release rather than reserving for a major version. That is a signal worth weighing before you pin a version.

Version 1.1.1, published 2025-09-15, is dependency maintenance: `vector_math` to 2.2.0, and dev dependencies `build_runner` 2.8.0, `mockito` 5.5.1 and `very_good_analysis` 9.0.0. Version 1.2.0, published 2026-03-13, is smaller still: a bug fix that honours the `enabled` property across `LineTouchData`, `BarTouchData`, `PieTouchData`, `ScatterTouchData`, `RadarTouchData` and `CandlestickTouchData` in one pass, a fix for a wrong bar colour when the value is small, and two mirrored values added to the `LabelDirection` enum. If you are upgrading, the touch data fix is the one with visible consequences: a disabled touch configuration that still reacted to input is exactly the kind of bug a shared code path across six charts can produce.

Reading the numbers before you depend on it

The repository has 7,578 stars and 1,970 forks, is not archived, and was pushed on 2026-09-19, so the work is current by any reasonable measure. It has 406 open issues. That ratio is the fact to plan around rather than a warning sign on its own: a package this widely used accumulates bug reports faster than any single maintainer can close them, and the release pattern above shows what actually gets through, which is small fixes against a moving Dart and Flutter toolchain rather than redesigns.

Licensing is straightforward. The repository is MIT, the README links the licence file directly, and the topics list includes `hacktoberfest`, which explains both the contributor volume and part of the issue backlog. The default branch is `main`.

So the practical reading is this. The API surface is broad, documented per chart with runnable samples, and exercised across desktop, mobile and web from a single example app. The feature work has slowed to a trickle of bug fixes and small additions, which is what you want from a widely depended upon widget library and not what you want if you need a roadmap. Pin your version, read the changelog before bumping, and treat the documentation files in the repository as the reference rather than any cached search result.

Editorial conclusion

fl_chart is the chart library a Flutter project reaches for first, and the reason is not raw capability so much as consistency: one `FlTitlesData`, one `AxisTitles`, one touch configuration object shared across all six chart families, so a dashboard does not need six mental models. What the repository tells you on a careful read is that the feature work has largely landed and the project has shifted into maintenance. Version 1.2.0 in March 2026 fixed two bugs and added two enum values. The open issue count of 406 against 7,578 stars is the number to weigh before you commit to it, because it means triage, not abandonment, is the bottleneck. Documentation is unusually good and unusually located, inside `repo_files/documentations/` rather than on a separate site, which is a benefit when you are reading source and a small cost when you are searching for it. Read the per chart markdown file, copy a sample, and keep your own version pin in mind.

Frequently asked questions

Official sources

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