rxdart: two packages, and the Flutter one is still at zero

It wraps the platform's own stream type rather than replacing it

The definition is one sentence and it contains the whole design decision.

RxDart is an implementation of the ReactiveX API for asynchronous programming, and it does that by leveraging the native Dart Streams API.

That second clause is what separates this from a port that brings its own abstraction. The composition primitives sit on the stream type the language and the platform already have, so anything that consumes a Dart stream can consume the result, and anything that produces one can feed it in. There is no wrapper object to unwrap at the boundary of your application.

The cost of that choice is that the library inherits the semantics of the underlying stream type rather than defining its own. If a question comes up about buffering, cancellation or error propagation, the answer starts with Dart's stream behaviour and then with what the library adds.

That is the mechanism. Everything else in this repository is packaging around it.

Two published packages on two release lines

The repository publishes two packages and they version independently.

| Package | Pub | |---------------------------------------------|-------------------------------------------------------------------------------------------------------------| | [`rxdart`](packages/rxdart) | [](https://pub.dartlang.org/packages/rxdart) | | [`rxdart_flutter`](packages/rxdart_flutter) | [](https://pub.dartlang.org/packages/rxdart_flutter) |

Each has its own directory under the packages folder and its own entry on the Dart package repository.

The release tags show how differently they move. The core package's newest tag is 0.28.0, dated in June 2024, with a development tag for the same version a few months earlier. The Flutter package's newest tag is a separate series entirely: a 0.0.1 dated in February 2025.

So a Flutter project adding the Flutter-flavoured package is pulling something that has had one tagged release, while a pure Dart project is pulling a package with at least twenty-eight tagged versions. Both are described in one readme, as one project, which is convenient for a reader and misleading for a version constraint.

Note also that both package links point at the older package repository host rather than its current one, which is the kind of redirect that works until it does not.

Flutter's own documentation places it beside Bloc

Two of the readme's links are external endorsements rather than project links, and they are the most informative lines in the file.

One points at the Flutter documentation's page on state management options, and it does so at an anchor covering Bloc and Rx. In other words, the framework that this library targets documents it as the reactive option alongside a competing approach written by a different community.

The other points at Flutter's page listing favourite packages and plugins, which is the mechanism by which a package declares that relationship. Both are links a maintainer adds deliberately, and neither is something the library can assert about itself.

The practical value is that a reader can check the claim independently. If you want to know whether a reactive library is a first-class option in Flutter's own guidance, that page answers it, and this readme hands you the address.

The remaining links are the ordinary ones: the test workflow, a workflow that builds the Flutter example, a coverage service, a chat room, the licence, and a hit counter.

Three example applications and two workflows

The examples directory holds three applications, and their names describe three different targets.

One is a Fibonacci example, which is the traditional way to show a stream or an iterable doing work lazily: each value depends on the two before it, so a generator or a stream is the natural expression. One is a Flutter example, and one is a web example.

So the library is exercised against a bare Dart console target, inside the widget framework, and in a browser build. That is the right set for a library whose substrate is a platform type, because it proves the composition operators behave the same in all three environments.

The workflows are named in the readme's badges: one runs the tests, and one builds the Flutter example. Both are referenced from the badge row rather than described anywhere, which is the pattern this project follows for its tooling.

Coverage is configured in the repository as well, with a configuration file at the root and a badge pointing at the reporting service. For a library whose behaviour is hard to see from its type signatures, that coverage badge is more informative than most of the prose would have been.

A Melos workspace with its own package manifest at the root

The build tooling is worth one paragraph because it explains the layout.

There is a Melos configuration file at the root. For Dart and Flutter repositories that tool orchestrates a workspace: several packages, shared commands across them, and version bumps that apply to all of them at once.

Alongside it are a package manifest and a lock file at the root, which is the part that is easy to misread. You would expect the manifest to live inside one of the two packages. It does not, so the root of this repository is itself a Dart package, and the two published packages sit beneath it.

That is a monorepo with a root project, which is a normal arrangement and has one visible consequence: a clone is immediately usable for workspace commands without installing anything first, and a contributor who edits the root manifest is changing something that is not published.

The rest of the root is conventional: a contributor guide, an authors file, a code of conduct, an agent instruction file, a licence, a coverage configuration, an assets directory for the readme's images, and a workflow directory.

Fifty-five words, one table, and no usage example

It is worth being precise about what this readme does and does not contain, because it is unusually short.

It contains a title, a badge block, one sentence defining the library, a heading for packages, a two-row table of those packages with links, and nothing else. There is no install command, no code example, no list of operators, no compatibility statement, no section on error handling, and no migration notes.

That is not an oversight in the sense of being unfinished. This library is one implementation of a documented API rather than the API itself, so the operator semantics belong to the ReactiveX documentation and the language-specific details belong on the documentation site, which is what the project links to.

The consequence for a reader is that the repository answers two questions well, which library is this and where do I get it, and defers everything else. Anyone evaluating whether the library covers their case has to leave the repository to do it.

For a package that has been in use for years, that division is defensible. For a first-time reader, it feels like arriving at a shop with a price tag and no stock.

The core release is two years older than the last push

The dates are the last thing to check, and they are the reason the version numbers matter.

The newest core tag is 0.28.0 from June 2024. The newest Flutter package tag is 0.0.1 from February 2025. The last recorded push to the default branch is dated 2026-06-15, and the repository is not archived.

So there are roughly two years of commits on the core package above its newest release. That is not unusual for a mature library, where maintenance continues without a version bump, but it has two consequences. A dependency constraint pinning the latest published version gives you code from June 2024, and the working tree you would read on the site is two years ahead of it.

The second consequence is about review. A library with no release for two years may have had fixes merged and not published, or may have had none. Nothing in the repository distinguishes those two cases, and the releases page is where you would look.

The last recorded push date is recent enough that this is a project receiving changes. Whether those changes are in a published version is the question the version constraint answers for you.

Editorial conclusion

rxdart fits a Dart or Flutter codebase that has already decided it wants the reactive composition style and is willing to use a library whose documentation lives on a site rather than in its repository. Three things to check before you depend on it. The core package's newest release tag is from June 2024 while the branch has moved since, so version pinning gives you a package that is two years behind the working tree. The Flutter-flavoured package is a separate release line still numbered 0.0.1. And this readme documents nothing about the operators themselves, so the API surface has to be read from the documentation site or from the package. Nothing here is a reason to avoid the library; all of it belongs in the first hour of adoption rather than the first week.

Frequently asked questions

Official sources

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