RxJS 9 has a GitHub release, and the npm next tag still points at RxJS 8

There is a 9.0.0-beta.0 release, and the file says it is not on npm

The repository has a release cut for the first planned beta, dated 2026-08-04, and the callout near the top of the file says that beta has not been published to npm yet. It adds two more facts in the same breath: the next tag still points to the earlier version 8 prerelease, and version 7 remains the production latest line and continues to be maintained. Those three sentences describe a package registry that is out of step with the repository, and the consequences are concrete. An unqualified install gives you version 7. Installing the next tag gives you a version 8 alpha whose last tags are dated December 2023 and January 2024. And a version number that looks like a beta in a release list is not something you can install. The last push to the master branch is dated 2026-08-08, so this is a recent state rather than a forgotten one.

The version number was chosen so an abandoned branch cannot be mistaken for it

A short section explains what happened to version 8, and the answer is a versioning decision rather than a feature list. Version 8 was real work, not a skipped release, and development on it began years ago before being paused while the Web Platform Observable proposal was finalised. The new implementation is a different generation, platform based, rather than a continuation of that paused branch, so it starts at version 9 to make the architectural break unmistakable and to avoid presenting the old version 8 work as the released product. Two tags make the gap visible: an alpha in December 2023 and another in January 2024, after which the line went quiet. So for anyone who evaluated an 8 alpha years ago, the code they tested is not what version 9 is, and the numbering exists specifically to stop that confusion.

Operators are Symbols, so you call them with bracket syntax

The preview of the planned beta API is short, and the shape of it is the whole point. Operators and factories are exact, module owned Symbols, and the library does not add string named methods to the platform API:

import { ColdObservable } from 'rxjs';
import { map } from 'rxjs/map';

const source = new ColdObservable<number>((subscriber) => {
  subscriber.next(1);
  subscriber.next(2);
  subscriber.complete();
});

source[map]((value) => value * 2).subscribe(console.log);

The file then draws the line you have to internalise: a platform method written with a dot remains the platform contract, while the same operator written with brackets is the separately versioned RxJS contract. Two contracts, one object, different owners, and a syntax change that a linter or a search and replace will not understand. Code that mixes them is depending on two things that are free to evolve apart.

Two subscription contracts, chosen by which class you import

Platform Observable behaviour and producer per subscription behaviour are described as explicit, separate contracts, and the file tells you when to use which: use the cold observable class when each direct subscription must create its own producer. That single sentence is the place where migrating code changes meaning rather than breaking. In an earlier version of the library, what happened when you subscribed twice was governed by convention and by hot or cold operators, and code that assumed a fresh producer per subscription could be wrong without failing. Here the choice moves to the constructor you call, which means a review has to check imports, not just operator chains. What the file does not give you is a default for the platform Observable when it is subscribed more than once, which is the detail a migration plan needs most.

The RxJS 7 test corpus is kept on purpose, and is not a compatibility gate

The contributing section contains the most useful sentence in the file for anyone planning an upgrade. The complete source pinned RxJS 7 corpus intentionally retains reviewed lifecycle and compatibility divergences, so it is migration evidence rather than a blanket RxJS 9 compatibility gate. The gates that matter are described as focused source, package, runtime, browser, performance and WPT commands. So the old suite is deliberately not green-washed into a compatibility promise, which is honest and also means that passing it tells you nothing about readiness. The migration path is the deliberate part of the layout: a dedicated migration package described as a deterministic migration engine, a package guide for it, and a separate RxJS 7 migration document in the main package. Migration is treated as a product here, not as a changelog.

Safari gets three release lanes, and the CI files themselves are linted as a test

The scripts in the manifest show how wide the release bar is. There are separate commands for the kernel, the polyfill lifecycle, release runtime, release browsers, release webpack, release performance and release adoption, and Safari appears three times: once for Safari, once for desktop Safari and once for Safari on iOS. Treating mobile Safari as its own lane is the clearest sign that it is not folded into a generic browser check. The check named for workflows is not a test of behaviour at all, it runs a formatter in check mode across the GitHub workflow files, the install action and the dependency bot config, so a misindented pipeline file fails the suite. The release check itself is a single long invocation of the node test runner across eight test files, followed by a vulnerability exception check, a package docs check and a release coherence check. Budget for a release process, not a single command.

One ESM build serves every supported runtime, and Node 26 is only advisory

The supported environments are stated as lanes rather than as a list. Node 22.13 and above and Node 24 are blocking lanes, and Node 26 is advisory. Current Chrome, Firefox, desktop Safari, mobile Safari, Deno, Bun and Webpack 5 are all blocking. Underneath that, published JavaScript is ESM only: there is no duplicate CommonJS build, and the current Node can bridge a require call to the same ESM files. The stated benefit is that every supported consumer receives the same implementation, so Deno and Bun support adds no runtime specific package and no application bundle code. That is a cleaner packaging story than dual builds, and it moves the compatibility question to your toolchain: a consumer on a CommonJS only path has to make the bridge work, and the manifest requires Node 22.13 or above with a pinned package manager version to build the repository at all.

Editorial conclusion

Read this repository as the design and gate documentation for a release that has not shipped, not as something to install. If you need RxJS now, the file says version 7 is the production line and still maintained, and it warns you off the next tag for version 9 specifically. Before you plan a migration, read the RxJS 7 migration document and the migration engine package, and budget for the two separate subscription contracts, because that is where existing code will change meaning rather than fail to compile.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. ReactiveX/rxjs on GitHub
4. README
5. Releases