EvilCharts: a shadcn and Recharts component site for React and Next.js

What EvilCharts is, and who it is actually for

EvilCharts is a website that doubles as a component source. The README describes it as "a modern, customizable chart library for React and Next.js applications", listing Bar, Line, Area, Pie and Radar as the supported chart types, with animation, responsiveness and what it calls customizable styles, patterns and effects. The homepage is evilcharts.com, and the repository is a Next.js application rather than a published library: package.json sets "private": true and the name is plain evilcharts at version 0.1.0.

That single field decides the audience. You cannot npm install evilcharts. The intended consumer is a developer who already runs shadcn and Tailwind in a React or Next.js app and wants chart components whose source lands in their own tree, where it can be edited. The site is the catalogue; the code is the deliverable.

If your team ships Vue, Svelte or plain server-rendered HTML, nothing here applies. Recharts is a React rendering layer, and every component in this project inherits that constraint.

The registry build is the real architecture

The interesting part of the repository is not the chart code, it is how the chart code reaches you. package.json defines three scripts that together form a small build pipeline: registry:build runs src/scripts/build-registry.mts through bun, registry:clean deletes public/r, registry.json and src/registry/__index__.tsx, and registry:fresh chains the two. The production build script is "bun run registry:fresh && next build", so every deploy regenerates the registry from source before Next.js compiles.

That is the shadcn registry pattern. A registry.json file sits at the repository root, the build script turns component sources into per-item JSON under public/r, and the website serves those files so a CLI can fetch them. The generated __index__.tsx is what the site itself uses to render previews.

The dependency list shows what the components are built from: recharts pinned at exactly 3.8.0, not a caret range, plus motion for animation, class-variance-authority, clsx and tailwind-merge for styling, and @number-flow/react for animated numbers. A second charting engine, echarts, is also present at ^6.1.0. The README does not explain why two engines coexist, so treat echarts as part of the site's own demo surface until you find a component that imports it.

The site scaffolding is fumadocs-core, fumadocs-mdx and fumadocs-ui, with shiki and rehype-pretty-code for code samples. None of that ships to your app when you copy a chart.

Installing EvilCharts and rendering a first chart

The README does not contain installation steps for consumers. It points to CONTRIBUTING.md for development setup and workflow, which is contributor guidance for running the site, not adopter guidance for pulling a component. So the honest path is: clone the repository and run the site locally, then read the component you want out of src/ and the registry entries out of registry.json.

The project uses bun, evidenced by bun.lock and by every script invoking bun run. From a clone, the development server starts with the dev script, which is next dev:

bun install
bun run dev

After that, Next.js serves the site on its default port and you should see the chart catalogue. Note that the plain dev script skips the registry build, so if a page depends on generated registry output, run the fresh variant instead:

bun run registry:fresh
bun run dev

That sequence deletes public/r, registry.json and src/registry/__index__.tsx first, then regenerates them from src/scripts/build-registry.mts. If the regeneration fails, the site will build against stale or missing index files, which is the most likely first failure you will hit.

Once you have the component source, the integration work is ordinary shadcn work: the component imports from recharts, so your app needs recharts 3.x and React 19 to match the versions the project pins. The README gives no minimum React version, so verify that yourself before copying code into an older app.

Where EvilCharts is the wrong tool

The README documents no rollback, no versioning scheme and no changelog, and the repository has no retrieved releases. With version 0.1.0 and "private": true, there is no published artifact to pin. If a copied component breaks after you edit it, the diff is yours to fix, and there is no upstream tag to diff against.

Peer version drift is the second risk. Recharts is pinned to exactly 3.8.0. If your application already depends on a different Recharts major, you are reconciling two versions of a rendering library inside one bundle, or upgrading your app. The README does not discuss this.

Third, the component list is short. Bar, Line, Area, Pie and Radar cover the common dashboard cases. The related searches around this project include phrases like "Shadcn Sankey diagram" and "Recharts Brush", but the README's feature list does not mention Sankey or brush controls, so do not assume either exists. If your requirement is a Sankey, a treemap or a Gantt view, this is not the project for it.

Finally, if you want a charting library you upgrade with a lockfile bump, this is structurally the wrong shape. Component-copy distribution means every future improvement is a manual merge.

How it compares with using Recharts directly

The obvious alternative is Recharts on its own, which is what EvilCharts wraps. The difference is where the design decisions live. With Recharts directly, you compose ResponsiveContainer, CartesianGrid, XAxis, YAxis and the series components yourself, and you own every default: axis tick styling, tooltip markup, legend spacing, empty states. That is more work and full control, and it is the right choice when your design system already specifies chart chrome.

EvilCharts front-loads those decisions. The README's claim is that the components are pre-designed and handcrafted, with styles, patterns and effects already applied through Tailwind classes and class-variance-authority variants. You get a finished look on day one and you inherit someone else's spacing and colour choices. Because the source is copied into your repository, you can change them, but you are now maintaining a fork of a component rather than configuring a library.

A second alternative is a heavier charting engine. ECharts, which appears in this project's own dependencies, is canvas-based and covers chart types Recharts does not. The trade-off is that it is imperative and does not compose as React elements, so it fits poorly into a codebase organised around shadcn components. Pick it when chart-type coverage matters more than React idiom.

Licence, maintenance and the cost of copying components

The repository is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is the whole of the licence implication here; whether your organisation's policy on vendored source applies is a question for your own legal review, not something the repository answers.

The last push to the default branch was on 2026-08-29, and the repository is not archived. That is recent enough that the codebase is not abandoned, but a single push date says nothing about cadence, and with no retrieved releases there is no version history to read for stability signals.

The upgrade cost is the part adopters underestimate. Because components are copied rather than installed, an upstream fix does not reach you through bun install. You either re-copy the component and reapply your edits, or you read the upstream diff and port it by hand. For a dashboard with three charts that is trivial. For a design system with thirty customised charts, the maintenance burden scales with every component you take.

Running the site versus adopting the components

These are two different jobs, and the repository serves both. Running evilcharts.com locally means installing the full dependency set: Next.js 16, React 19.2.3, fumadocs, shiki, zustand, cmdk, embla-carousel-react, react-dnd and the rest. That is a documentation site with a command palette and a component playground, and the install is heavy because of it.

Adopting one chart means taking a single file plus its imports. The chart itself needs recharts and your styling utilities; it does not need fumadocs, shiki or the analytics packages. If you find yourself installing @axiomhq/js or @vercel/analytics to make a bar chart work, you have copied site code instead of component code.

That distinction also explains the registry scripts. They exist so the site can publish components as standalone JSON, separating the catalogue from the artefacts. When you go looking for a component, prefer the registry output over the site's page source, because the page source may include demo-only wrappers that the registry entry strips out.

Editorial conclusion

Adopt EvilCharts if you already run shadcn, Tailwind and Recharts and want pre-styled Bar, Line, Area, Pie and Radar components you can edit in your own repo. Do not adopt it if you need charts outside React, a maintained npm package with semantic versioning, or a documented upgrade path; the README documents no install command, no release history and no migration guide. Before committing, run bun run dev on a clone and open a chart page to confirm the Recharts 3.8.0 peer resolves against your React version, then check whether the component you want exists as a registry item in registry.json rather than only in the website's own pages.

Frequently asked questions

Official sources

1. Issues
2. legions-developer/evilcharts on GitHub
3. License: MIT
4. Project website
5. README