xyflow ships React Flow 12, Svelte Flow, and a shared layer still sitting at 0.0.83

Four packages, and the shared layer is still on a 0.0.x line

The repository is the home of four packages: React Flow 12 as @xyflow/react in packages/react, React Flow 11 as reactflow on a separate v11 branch, Svelte Flow as @xyflow/svelte in packages/svelte, and a shared helper library @xyflow/system in packages/system. The version numbers on those three live packages tell you more than the list does. On 2026-09-24 the same day, @xyflow/react went out at 12.12.0, @xyflow/svelte at 1.7.0, and @xyflow/system at 0.0.83, all within seconds of one another. A shared layer that has never left the 0.0.x range is a signal about its own stability promise, and it matters because the two editor libraries both sit on top of it. If you take a direct dependency on @xyflow/system you inherit a package the maintainers themselves version as provisional, and you have to keep it aligned with whichever editor version you chose.

React Flow 11 lives on a branch, not on the main line

One of the four packages is not on the default branch at all. React Flow 11 is published under the bare name reactflow and its source sits in a v11 branch, while the default branch main carries React Flow 12 under the scoped name @xyflow/react. The import path changed with the major, which is the usual reason for a scope, and it means a migration is not a version bump but a rename of the package you depend on and of every import inside your source. The branch arrangement has a second consequence. If you are still on 11, your fixes do not arrive on the same day as fixes for 12, because they are cut from a different line, and the repository's own release machinery is described in terms of merging into main. Nothing in the file states how long the v11 branch will receive patches, so the schedule you are relying on is one you have to confirm rather than one you can read off a page.

Nothing publishes itself, and one changeset bumps everything

Releases run through changesets and a changeset GitHub action in four steps: open pull requests for features and fixes, merge into main, let changeset open a pull request that bumps all packages based on the changesets, then merge that changeset pull request if you want to release to GitHub and npm. Two things follow. First, publication is a manual act. The word if in the last step means a merged fix sits on main and on nobody's npm install until a person merges the second pull request, so the gap between a commit landing and a version existing is a human action, not a pipeline. Second, the bump covers all packages rather than the affected ones, so a change isolated to the Svelte package can still produce version movements elsewhere in the set. If you depend on exact pins, expect your lockfile to churn on packages you never touched.

The clone rejects npm while the consumer install does not

The root package.json carries a preinstall script that runs npx only-allow pnpm, and the file also pins packageManager to [email protected], with pnpm-workspace.yaml and pnpm-lock.yaml at the root. The practical effect is a hard stop for anyone who clones the repository and reaches for npm, and it happens before any dependency is fetched. That guard applies to the monorepo only. The README tells consumers to install the library with npm, and there is no contradiction, because the preinstall hook is a script in a package marked private at version 0.0.0, so it never runs when someone installs the published package into their own project. The distinction is worth holding on to: a contributor needs pnpm and turbo before anything compiles, while a user of @xyflow/react needs nothing from this repository at all.

npm install @xyflow/react

npm install @xyflow/svelte

The root checks stop at packages/ and never reach the examples

The build, lint, and typecheck scripts are all scoped. Build and typecheck and lint each run through turbo with a filter of ./packages/**, and the clean script walks the workspace in parallel to remove dist, .turbo, and node_modules. The examples directory holds three projects, examples/react/, examples/svelte/, and examples/astro-xyflow/, and none of them is inside that filter. The test scripts are scoped differently again, each one filtering to a workspace package named playwright, a name that does not appear among the top-level entries, so a first-time contributor has to find it before they can run a test. The net effect is that the examples are the least checked part of the repository. The Astro case is the sharpest: there is a working Astro example in the tree and no Astro package among the four published ones.

TypeScript is pinned to one version while every other dependency floats

In the development dependencies almost everything carries a caret range: eslint at 8.57.0, rollup at 4.18.0, turbo at 2.0.3, @playwright/test at 1.44.1, and prettier at 3.7.2. TypeScript is the exception, written as an exact 5.4.5 with no range at all, and React and React DOM are held at 18.2.0. The exact pin tells you the repository's typecheck runs against one compiler version, which is a defensible choice for a library shipping its own type definitions. The consequence lands on you rather than on them. Your application compiles with whatever TypeScript you have chosen, so it is entirely possible for the library to pass its own typecheck against 5.4.5 and for you to hit type errors under a newer compiler. If a types upgrade is the thing blocking you, that gap is the first place to look, and the repository's pin is the reason it can happen at all.

The stylesheet is a side-effect import that nothing checks for

Both basic usage samples import the package stylesheet as a side effect, right alongside the component imports, and the two lines differ only in the package name. That import is not optional decoration. A React Flow canvas without its stylesheet has nodes, edges, and viewport that are mounted and interactive but unstyled, which reads as a broken build rather than a missing asset. The risk comes from how side-effect CSS imports behave in bundlers, since a tree-shaking pass that treats the import as having no used exports can drop it depending on configuration. The cost of getting this wrong is a blank or mispositioned canvas and an afternoon of debugging your node coordinates instead of your bundler settings. The rest of the React sample is a standard shape, with initialNodes carrying an id, a position, and a data object, and initialEdges carrying an id, a source, and a target.

import { useCallback } from 'react';
import {
  ReactFlow,
  MiniMap,
  Controls,
  Background,
  useNodesState,
  useEdgesState,
  addEdge,
} from '@xyflow/react';

import '@xyflow/react/dist/style.css';

MIT terms, and the money request aimed at organizations

The licensing position is unambiguous: React Flow and Svelte Flow are MIT licensed, and there is a LICENSE file at the root. The commercial usage section adds a distinction that is worth reading carefully. For a personal project, no sponsorship is needed, and the suggested support is reporting bugs, sending screenshots, and starring the repository. For an organization making money from it, the README says the team relies on that support to keep the libraries developed under the MIT terms they prefer, and names two channels: the React Flow Pro website for React Flow, and GitHub Sponsors for both libraries. There is no legal obligation in any of it, and no feature is withheld under the MIT grant. The asymmetry to notice is that no Pro equivalent is named for Svelte Flow, so a paying organization running the Svelte package has one listed route rather than two.

Editorial conclusion

React Flow is the right pick if you are building a node editor in React and want the state hooks, the minimap, and the controls already written, and the MIT terms mean you can ship it without asking anyone's permission. Svelte Flow is the same idea with a deliberately different state model, so neither the code nor the habits transfer between the two. Before you commit, confirm which major line you are on, because React Flow 11 sits on its own branch while 12 sits on main, add the stylesheet import on day one, and remember that nothing reaches npm until a person merges a changeset PR. If your build has to be reproducible, pin the react, svelte, and system versions together rather than taking the latest of each.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes