plouc/nivo: React chart components built on d3, scoped package by scoped package

The problem nivo solves, and who ends up using it

React and d3 do not fit together naturally. d3 wants to own the DOM node and mutate it; React wants to own the DOM and re-render it from props. Most projects that need charts in a React app end up choosing between writing d3 code inside a useEffect hook and losing React's declarative model, or using a charting library that hides d3 entirely and limits what you can customize.

nivo takes the second path but keeps the escape hatches. The README describes it as providing "supercharged React components to easily build dataviz apps, it's built on top of d3", and notes that while several libraries exist for React d3 integration, "just a few provide server side rendering ability and fully declarative charts". That second clause is the actual positioning. The audience is a frontend team that already has a React app, wants charts as components with props, and does not want to hand-write scales, axes and transitions.

The repository is a monorepo. The top-level entries include packages/, website/, storybook/, cypress/, api/, and a Makefile, with lerna.json and pnpm-workspace.yaml at the root. The language is TypeScript, the licence is MIT, and the last push was on 2026-07-21. The most recent release listed is v0.99.0 from 2025-05-23, still below 1.0, which is worth knowing before you pin a version.

How the scoped packages and renderers fit together

nivo is not one import. The README states that to use it "you have to install the `@nivo/core` package and then choose some of the scoped `@nivo` packages according to the charts you wish to use". So @nivo/core is the shared base, and each chart type is its own package, which is why the search terms people use include Nivo/core, Nivo/bar and Nivo line: those are package names, not features.

The rendering story is the part that separates nivo from a typical React chart wrapper. The feature list names SVG Charts, HTML Charts and Canvas Charts as three distinct categories, each with its own filter on the site. The same chart concept can exist in more than one renderer, and the choice is made per component rather than for the whole library. Canvas matters when you have enough data points that thousands of SVG nodes become the bottleneck; SVG matters when you need real DOM nodes for accessibility tooling or CSS. The README does not state a threshold for switching, so that decision is yours to measure.

Around the charts sit cross-cutting guides, listed as Axes, Colors, Legends, Gradients, Patterns and Theming. Those are documented as shared concerns rather than per-chart options, which is the main reason the package split does not fragment configuration as badly as it looks. Motion and transitions are handled by react-spring, per the feature list, and there is a Components Explorer on the site for browsing what exists.

Installing @nivo/core and rendering your first bar chart

The README gives a single install example using yarn, adding @nivo/core plus the chart package you want:

yarn add @nivo/core @nivo/bar

The equivalent with npm is the same two package names. After that you import the chart component from its own package and pass data and props. The README does not include a full component example, so the exact prop names for a bar chart are not something to guess at here; the site's Components Explorer and the bar package's own documentation are where the prop list lives.

The repository itself is a pnpm workspace, and the Makefile exposes the contributor path rather than a consumer path. The help target prints the available targets, and the global install target is:

make install

which the Makefile defines as running `pnpm install`. There is also an init target documented as running clean-all, install, pkgs-build and a storybook/playwright step, plus targets for the website, storybook and deploys. Those are for working on nivo, not for using it. If you are consuming nivo in an app, the two npm packages are the whole story and you never need the Makefile.

For server side rendering, the README lists "Server Side Rendering and HTTP API" as a feature, and the repository contains an api/ directory with Dockerfile.nivo-api and a Procfile at the root. That is the infrastructure behind the site and its chart rendering service, not a package you install. The README does not document an npm-installable server-side rendering entry point beyond the general claim, so treat SSR as something to verify against the docs for your specific chart before designing around it.

Where the per-chart package model costs you

The scoped package split is the design decision with the most consequences, and it cuts both ways. On the plus side, importing @nivo/bar does not pull in the code for a sunburst or a chord diagram. On the minus side, a dashboard with six chart types means six dependencies to add, six version numbers to keep aligned with @nivo/core, and six entries in your lockfile diff every time you upgrade.

Version skew is the real risk. Because the packages are published together from one monorepo but installed separately, a partial upgrade can leave @nivo/core at one version and @nivo/bar at another. The repository uses lerna and a pnpm workspace, and the release history shows multiple versions landing within days of each other (v0.97.0 and v0.98.0 both on 2025-05-16, v0.99.0 a week later), which is consistent with coordinated releases. Nothing in the README describes a compatibility matrix between core and chart package versions. If you pin, pin them together.

The other limitation is that nivo is a React library. The components are the product; d3 is described as the foundation underneath. If your charting need is inside a Vue, Svelte or plain-DOM application, or if you want to generate charts in a Node script with no React runtime, nivo is the wrong tool. The isomorphic and server-side-rendering topics suggest that path exists, but the README frames the library as React components, and the api/ directory is a deployed service rather than a general-purpose headless renderer. There is also no documented rollback procedure for a bad upgrade in the README, so plan on being able to revert your lockfile.

nivo versus reaching for d3 directly or a single-package chart library

The honest alternative is d3 itself. With d3 you write the scales, axes, shapes and transitions yourself against a DOM node you control. You get exactly the chart you want and no dependency on someone else's prop API. You also own every interaction, every tooltip position and every accessibility attribute, and you reimplement them for the second chart type. nivo's proposition is that the declarative React wrapper plus the guides for axes, colors and legends remove that repeated work, at the cost of working within its prop surface.

The other alternative is a charting library that ships as one package with every chart type included. That removes the version-alignment problem described above and usually means fewer decisions at install time. What you give up is the per-component renderer choice: nivo exposes SVG, HTML and Canvas as separate chart categories you pick between, and a single-package library typically commits to one rendering strategy across the board. If your data volume varies a lot between views, that difference matters more than the install convenience.

Between these, nivo sits in a specific spot: more structure than raw d3, more renderer flexibility than a monolithic chart package, and more packages to manage than either.

Licence, maintenance signals and the upgrade cost you are signing up for

nivo is MIT licensed. The root package.json carries a licenses array with the MIT type and a link to LICENSE.md, and the README links the same licence file. MIT is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice travel with it. That is the general shape of the licence, not legal advice; read LICENSE.md yourself if the distinction matters to your organisation.

On maintenance, the repository is not archived and the last push was on 2026-07-21, which is recent enough that the project is being worked on. The release cadence visible in the release history is uneven: three releases in May 2025, then nothing newer listed. The version number is still 0.x, and the README does not promise API stability. For a library whose entire value is a prop API, that is the upgrade cost you are accepting: minor-version bumps may change props, and with one package per chart type you may be chasing several of them at once.

The contributor workflow is heavier than a typical library. The Makefile documents targets for install, init, pkgs-build, pkgs-publish, website and storybook builds and deploys, and the repository carries cypress/ and storybook/ directories. That is a real cost only if you intend to patch nivo rather than consume it. If you are consuming it, your upgrade loop is npm install, check your charts, and revert the lockfile if something moved.

Editorial conclusion

Adopt nivo when you are rendering charts inside a React tree and want the renderer choice (SVG, HTML or Canvas) to be a per-component decision rather than a library-wide one, and when you can live with installing one scoped package per chart type. Skip it if you need a single dependency with every chart included, or if your charts live outside React, since the components are React components first and the d3 layer is an implementation detail. Before committing, check the version of @nivo/core and your chosen chart package on npm, confirm the chart type you need exists in the Components Explorer, and read the theming and legends guides rather than assuming the defaults will match your design system.

Frequently asked questions

Official sources

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