super_editor: a mono-repo editor where the branch name is part of the dependency

It is a toolkit, and the editor is only one part

Super Editor is described as an open source, configurable, extensible text editor and document renderer for Flutter. The emphasis on configurable and extensible is the design statement, and the renderer in that phrase matters: the project splits editing from rendering rather than coupling them in one widget.

It is also a mono-repo, and the README is explicit that this is deliberate. The claim is not just building an editor but building a document editing toolkit, with the editor being the visible part of a set of supporting projects. Three are highlighted with their own READMEs: `super_editor` itself, `super_text_layout` for text layout, and `attributed_text` for the text model that carries formatting.

The top-level directory listing shows how far the toolkit goes. Besides those three there is `super_editor_markdown`, `super_editor_clipboard`, `super_editor_spellcheck`, `super_keyboard`, `super_clones`, `flutter_test_registry`, a `website/` directory, and `doc/`.

Two of those names explain themselves. `super_keyboard` suggests the keyboard layer is separable rather than baked into the editor, and `super_editor_spellcheck` suggests spell checking is a package you add rather than a feature you wait for. `flutter_test_registry` is the one to note if you write golden tests, since golden testing needs deterministic rendering and a shared registry of test fixtures.

The project was initiated by Superlist, and is implemented and maintained by Flutter Bounty Hunters, Superlist, and contributors.

The branch you depend on is decided by your Flutter channel

This is the single most important operational detail in the README, and it is stated twice in one paragraph.

If you use Flutter's stable branch, check out super_editor's `stable` branch, for compatibility. If you use Flutter's master branch, check out the `main` branch, for compatibility.

So the Flutter channel you are on determines which git ref you point at. That is a compatibility requirement, and it is easy to miss when declaring a Git dependency because the ref must be selected explicitly.

The same section makes a related point: your project does not need to use Pub to use Super Editor, because you can depend directly on the GitHub repository to keep up with the latest changes. That flexibility is exactly why the branch matters.

A web demo is available at superlist.com/SuperEditor if you want to see the editor running before deciding.

Mono-repo versioning is a real operational cost

The README warns that you may hit compilation errors when using the GitHub version of super_editor, and tells you why: this project often makes changes to multiple packages within the mono-repo, which requires that you use the latest main or stable version of every package.

The fix is dependency overrides, and the README gives the full block:

dependency_overrides:
  super_editor:
    git:
      url: https://github.com/superlistapp/super_editor
      path: super_editor
      ref: stable # or "main"
  super_editor_markdown:
    git:
      url: https://github.com/superlistapp/super_editor
      path: super_editor_markdown
      ref: stable
  super_text_layout:
    git:
      url: https://github.com/superlistapp/super_editor
      path: super_text_layout
      ref: stable
  attributed_text:
    git:
      url: https://github.com/superlistapp/super_editor
      path: attributed_text
      ref: stable

Four entries, each with a `path` into the same repository and a `ref`. Note that the URL in the example is `superlistapp/super_editor` while the repository is `Flutter-Bounty-Hunters/super_editor`, so the example reflects a former or alternate location and you may need to adjust it.

What this means in practice is that adding Super Editor to a project is not adding one dependency. It is committing to tracking a set of packages at one ref, and updating them together. A ref bump is a coordinated change to your pubspec, and if you have any of these packages pinned from Pub while others come from git, you have two sources of truth.

The upside is that you get the latest core work rather than waiting for a release. The README states plainly that no standard release has been cut in a long time.

Why there has been no release, stated by the maintainers

The note on releases is dated June 2024 and it is the most useful paragraph in the README, because it explains the absence of a published version rather than leaving you to infer it.

The stated reason is that the maintainers have been busy at work on core editor improvements: undo/redo, a stable editor pipeline, and editor reactions. Those APIs have evolved a lot, so no standard release has been cut in a long time, and they are still evolving those APIs right now.

That names three concrete areas of churn. Undo/redo is the one most applications depend on heavily, so an unstable undo API is a real problem for anyone shipping an editor. The editor pipeline suggests the internal request and change flow is still moving. Reactions is another evolving API surface.

The note also says developer releases are now being published so the community can see what is being worked on, and reiterates that the project is under regular development and still active.

So the correct reading is not that the project is abandoned or that the editor does not work. It is that the core APIs are in flux and the maintainers chose to land that work rather than freeze it behind a release. That is a defensible choice and an expensive one for adopters, and you should decide which side of that trade you are on before integrating.

Backend-agnostic is the architectural commitment

The header states it plainly: Super Editor works with any backend, plug yours in and go. No documentation is needed to explain what that excludes, because the alternative is an editor that carries a persistence model with it.

For a team building a document product, that is the whole reason to reach for a toolkit rather than a widget. The editor, the document model, and the text layout are separable packages, so a Flutter application can store documents in a local database, sync them to a server, or hold them in memory for a prototype, without the editor knowing.

The separation is visible in the package list. `super_text_layout` handles layout independently of editing, which means text rendering is not locked to the editor's widget tree. `attributed_text` holds the attributed text model, which is the data structure the editor reads and writes. `super_keyboard` separates input handling. `super_editor_clipboard` and `super_editor_spellcheck` are capabilities you attach rather than configuration you enable.

There is no documentation of the actual document persistence format or of an editor-to-backend interface in the README, so the shape of that integration is something you will need to find in the package READMEs under `super_editor/`.

The licence is MIT, in the `LICENSE` file at the root, and there is a `README_FUNDING.md` alongside it.

Testing infrastructure suggests how seriously this is built

Two repository entries exist purely for testing, and they say more about the project's engineering than the feature list does.

`flutter_test_registry` is a package rather than a test directory, which means test fixtures and registration are shared across the mono-repo's packages. That is what makes it possible for several packages to test against the same golden images.

`golden_tester.Dockerfile` is the more revealing one. Golden tests compare rendered output against reference images, and comparing them reliably requires a controlled environment: the same font rendering, the same platform, the same Flutter version. A Dockerfile exists to pin that environment, which is the standard solution and not an unusual thing to find. Finding it at the repository root tells you golden testing is a routine part of the workflow rather than an occasional chore.

Combined with the `.dockerignore` at the root, the repository includes container-related testing infrastructure.

The `website/` directory suggests documentation is maintained in the repository rather than only on a separate site, and `doc/` holds additional material. None of this is in the README, so it is worth a look before deciding the project is undocumented.

Editorial conclusion

Adopt super_editor if you are building a document editor in Flutter and want a backend-agnostic editor rather than a note-taking widget, since the project works with any backend by design. Do not adopt it if you need a published, stable release, because the README states no standard release has been cut in a long time while undo/redo, the editor pipeline, and reactions were evolving. Verify first which Flutter channel you are on and pin every mono-repo package to the matching ref, because mismatched mono-repo package versions can cause compilation errors.

Frequently asked questions

Official sources

1. Flutter-Bounty-Hunters/super_editor on GitHub
2. Issues
3. License: MIT
4. Project website
5. README