Flume gives your React app a node editor with typed ports

Ports and node types are declared in a config object

Flume's model is that a graph has a small vocabulary, and you describe that vocabulary before rendering anything. A FlumeConfig collects two things: port types, which define what can flow on a connection, and node types, which define what a node is called, how wide it starts, and which ports it has.

The README's first example registers a number port type with a control attached, then a number node with one input and one output, then an addNumbers node with two inputs and one output. Each port type carries a type key, a name, a label, a color and a list of controls; each node type carries a type key, a label, an initialWidth and functions receiving the port helpers.

The design point is that the editor has no hardcoded node types. A flowchart for an audio pipeline and one for a data pipeline differ only in the config object you pass in, which is what makes the library reusable across domains.

Rendering is a div with a width and a height

The consumer side is deliberately small. You import NodeEditor and hand it the nodeTypes and portTypes from your config:

import React from 'react'
import { NodeEditor } from 'flume'
import config from './config'

const App = () => {

  return (
    <div style={{width: 600, height: 800}}> // Give the wrapper a width & height
      <NodeEditor
        nodeTypes={config.nodeTypes}
        portTypes={config.portTypes}
      />
    </div>
  )
}

The comment in the README about giving the wrapper a width and a height is the whole layout contract. Flume does not impose a size, so a parent that collapses to zero height produces an editor with no visible canvas and no error to explain why.

The documentation site flume.dev holds the guides and examples; the repository README stays at the two snippets above and delegates everything else.

What the releases say about the feature set

The version history is short enough to read as a roadmap of the editor's rough edges. v1.0.4 in September 2023 was a TypeScript rewrite, which is why the README examples are JSX despite the package being written in TypeScript. v1.1.0 in March 2025 added prettier connections, which is about how links are routed between ports. v1.2.0 in November 2025 improved cyclic detection.

That last one is worth pausing on. Cyclic detection in a node graph is the difference between a useful editor and one that hangs the tab when a user connects a node back into its own ancestor. The feature arrived late and the release note says improved rather than fixed, so test cycles explicitly with your own node shapes.

The last push was on 2026-04-12, and v1.2.0 is still the newest release. The library is not archived, but it is not moving quickly either.

React 18 is a peer dependency, and the Node requirement is stale

The manifest declares peerDependencies on react ^18.2.0 and react-dom ^18.2.0 alongside prop-types ^15.5.4. Peer dependencies are how the package avoids shipping its own React, and it also means your app has to satisfy them.

The engines field is a different story. It asks for node >=8 and npm >=5, which reflects when the package was first written rather than what it needs now, given a TypeScript rewrite and Cypress integration tests. Treat the engines field as documentation of history, not as a supported range.

For consumers on React 19, nothing in the repository says whether the peer range has been widened, so check the installed peer range yourself before assuming compatibility. That is a two minute check that avoids a confusing runtime warning later.

Testing is Jest plus a real Cypress run

The test script is not a single runner:

"test": "jest && npx cypress run",
"test:coverage": "jest --coverage",
"test:watch": "jest --watch"

So the unit tests come from Jest, configured through jest.config.js and jest.setup.js, and a Cypress suite runs afterwards in a real browser. There is a cypress/ directory and a cypress.json at the repository root, and a __mocks__/ directory for Jest module mocks.

That combination is the interesting signal about the project. Node editors fail on pointer interaction, connection dragging and layout, none of which a DOM-less unit test can check, so the Cypress layer is the part that actually verifies the library's core behaviour. If you fork this, keep the Cypress tests.

Build and release go through Rollup and Changesets: rollup -c produces the bundle and changeset publish handles versioning, with a .changeset/ directory tracking pending releases.

What the library does not give you

The README does not describe persistence, and that is the largest gap for anyone building on top. You get a canvas and a set of nodes; where a graph is stored, how it is versioned and how it is shared is not part of the library.

Nor does the README cover validation rules. Controls are attached to port types, which suggests input configuration on a node, but there is no described mechanism for rejecting a graph that cannot execute.

If you need an editor where users author a workflow that then runs, Flume supplies the surface and everything with semantics is yours. That is a reasonable division for a library, and it is also why the documentation site rather than the README is where the real examples live.

Licence, packaging and repository layout

Flume is MIT licensed, held in LICENSE at the repository root and credited to chrisjpatty in the README. The package is marked private false and publishes to npm as flume, with main pointing at dist/index.js and both module and jsnext:main at dist/index.es.js, so bundlers pick the ES module build.

The repository root is conventional for a TypeScript library: src/, docs/, example/, cypress/, rollup.config.js, tsconfig.json and an .editorconfig. There is a logo.ai and logo.svg, and the README is illustrated with readme-header.jpg showing a live editor.

Contributing is governed by CODE_OF_CONDUCT.md, and CHANGELOG.md at the root records the release history referenced above.

Editorial conclusion

Adopt Flume if your React application needs a visual pipeline editor and you can accept defining its vocabulary in code rather than in JSON at runtime. Do not expect a complete editor product, since graph persistence, undo of your own business actions and validation are outside what the README covers. Verify first that your React version matches the peerDependencies of react and react-dom ^18.2.0, and check CHANGELOG.md before moving from a pre 1.2.0 build.

Frequently asked questions

Official sources

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