Mixed — Stale — last commit 1y ago

• 18 active contributors
• Apache-2.0 licensed
• Tests present
• ⚠ Stale — last commit 1y ago
• ⚠ Concentrated ownership — top contributor handles 59% of recent commits
• ⚠ No CI workflows detected

Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against dependency CVEs from deps.dev and OpenSSF Scorecard

RxJS is a production-grade reactive programming library for JavaScript that implements the Observable pattern, enabling declarative handling of asynchronous data streams, events, and state changes. It provides composable operators like map, filter, combineLatest, and switchMap that transform, combine, and manage streams of values over time—solving the complexity of managing callbacks, promises, and event listeners in callback-heavy or event-driven applications. Monorepo structure: core library at packages/rxjs/src/ with internal/ containing core abstractions (Observable, Subject, Scheduler, Operators), observable/ with creation functions (of, from, interval, merge, combineLatest), operators/ with composable transformation operators, and ajax/fetch for HTTP. Documentation app at apps/rxjs.dev/. Built with TypeScript, tested with Jasmine/Karma, and bundled for both ESM and CommonJS.

LLM-derived; treat as a starting point, not verified fact.

JavaScript/TypeScript developers building real-time applications (dashboards, chat systems, collaborative editors), UI libraries (Angular uses RxJS heavily), and anyone managing complex asynchronous workflows who want to avoid callback hell and pyramid-of-doom promise chains. Contributors are typically reactive programming enthusiasts and maintainers of downstream frameworks.

LLM-derived; treat as a starting point, not verified fact.

Highly mature and production-ready: RxJS v7.x is stable (6.x branch still supported), v8 is in active development on master. Strong CI/CD setup (GitHub Actions), comprehensive test suite (monorepo with dedicated test runs via yarn workspace rxjs test), official documentation site at rxjs.dev, and Apache 2.0 licensed. Used at scale by Angular, Netflix, and many enterprises.

Low risk for stability, high risk for breaking changes on master (v8 rewrite is deliberately incompatible): master targets v8 which simplifies the API surface. Dependencies are lean (mostly TypeScript tooling), but monorepo complexity (packages/ + apps/) requires careful workspace management. Single-maintainer risk is typical for large open-source; check GitHub stars and recent commit frequency to confirm active maintenance on your target branch (7.x vs master).

LLM-derived; treat as a starting point, not verified fact.

v8 development is active on master (rewrite focusing on performance and API simplification). The codebase shows recent work on internal operators and observable creation functions. No specific major feature PRs visible from file list alone, but the v8 branch is the primary focus—v7.x maintenance on the 7.x branch, v6.x on 6.x branch. Documentation at rxjs.dev is actively maintained.

LLM-derived; treat as a starting point, not verified fact.

git clone https://github.com/ReactiveX/rxjs.git
cd rxjs
yarn install
yarn workspace rxjs test
yarn workspace rxjs.dev start

First command runs the test suite for the core library; second starts the documentation site on localhost:4200 (from apps/rxjs.dev/ Angular app).

Daily commands:

yarn workspace rxjs test          # Run RxJS test suite
yarn workspace rxjs.dev start     # Start dev docs server (localhost:4200, Angular dev server)
yarn workspace rxjs.dev build     # Build production docs bundle

Use yarn workspace rxjs <script> to target the core library, yarn workspace rxjs.dev <script> for the docs site.

• packages/rxjs/src/index.ts — Main entry point exporting all public Observable, Subject, and operator APIs that form the library's core contract.
• packages/rxjs/src/internal/Observable.ts — Core Observable class implementing the subscribe contract; every reactive chain builds upon this foundation.
• packages/rxjs/src/internal/Subject.ts — Subject implementation enabling both observer and observable patterns; critical for multicast and state management.
• packages/rxjs/src/internal/Scheduler.ts — Scheduler abstraction controlling execution timing and concurrency; essential for understanding async behavior.
• packages/rxjs/src/internal/Subscriber.ts — Subscriber class managing subscriptions and unsubscriptions; handles the actual observer lifecycle.
• packages/rxjs/src/internal/operators/map.ts — Prototypical operator implementation demonstrating the standard pattern all 60+ operators follow.

• Observable (TypeScript classes, generic types, higher-order functions) — Lazy container for async value streams; stores subscription function and implements pipe() for operator composition.
  • Failure mode: If subscription function throws or never calls complete/error, subscribers hang indefinitely.
• Subject & Variants (Behavior, Replay, Async) (TypeScript classes extending Observable, internal value buffer/ring) — Multicast observers that also emit values; enable hot observables and state sharing across subscribers.
  • Failure mode: Unmanaged Subject subscriptions leak memory; ReplaySubject buffer can exhaust memory on infinite streams.
• Operators (map, filter, mergeMap, etc.) (Functional composition, Subscription management, nested observables) — Higher-order functions returning Observables; transform or filter values, handle async flattening, and manage inner subscriptions.
  • Failure mode: Inner subscription leaks in mergeMap/concatMap if not properly unsubscribed; backpressure not handled without custom logic.
• Scheduler (Queue data structures, timer APIs (setTimeout, requestAnimationFrame), microtask recursion) — Controls execution timing via action queueing (async, asap, animationFrame, or synchronous); decouples observable definition from timing.
  • Failure mode: Scheduler starvation if actions queue faster than dequeue; can cause missed frames or UI blocking.
• Subscription & Unsubscribe (Cleanup function registry, subscription tree traversal) — Manages resource lifecycle; tracks cleanup functions and propagates unsubscribe to parent and child subscriptions.
  • Failure mode: Broken unsubscribe chain leaves dangling listeners and timers; causes memory leaks in long-running applications.
• AJAX & Fetch Integration (XMLHttpRequest, Fetch API, AbortController) — Wraps XMLHttpRequest and Fetch APIs as observables; handles response parsing, error, and request cancellation via unsubscribe.
  • Failure mode: Unsubscribe does not abort in-flight requests if AbortController not used; wastes bandwidth and memory.

• Observable source → Operator 1 (pipe) — Source observable passed to pipe chain; first operator wraps it.
• Operator N-1 → Operator N — Each operator returns new Observable wrapping previous; forms composition chain.
• Final operator Observable → Subscriber.subscribe() — Subscribe called on final observable; unwinds operator chain to source subscription.
• Source subscription function → Scheduler (if specified) — Subscription logic queued to scheduler for deferred or batched execution.
• Scheduler action → Observer (next/error/complete) — Emissions flow through operator chain, each transforming and passing values downstream to observer.
• Observer.error() or unsubscribe() → Cleanup handlers (finalize) — Errors or unsubscribe trigger cleanup; finalize operators run, resources released, parent unsubscribed.

Add a New Operator

1. Create operator file following the map.ts pattern in packages/rxjs/src/internal/operators/ with return of (source) => new Observable(subscriber => source.subscribe(...)) (packages/rxjs/src/internal/operators/myOperator.ts)
2. Export operator from packages/rxjs/src/operators/index.ts alongside existing operators (packages/rxjs/src/operators/index.ts)
3. Add type signatures and operator descriptors for documentation generation (packages/rxjs/src/internal/operators/myOperator.ts)
4. Create unit tests in packages/rxjs/spec/operators/myOperator-spec.ts validating subscription, values, and error paths (packages/rxjs/spec/operators/myOperator-spec.ts)

Add a New Observable Creation Function

1. Create factory in packages/rxjs/src/internal/observable/myObservable.ts returning Observable with subscription logic (packages/rxjs/src/internal/observable/myObservable.ts)
2. Export from packages/rxjs/src/observable/index.ts in alphabetical order (packages/rxjs/src/observable/index.ts)
3. Re-export from main index.ts to make publicly available (packages/rxjs/src/index.ts)
4. Write tests covering synchronous emission, async cases, completion, and error scenarios (packages/rxjs/spec/observables/myObservable-spec.ts)

Add a New Subject Variant

1. Extend Subject base class in packages/rxjs/src/internal/MySubject.ts overriding _subscribe() for custom multicast behavior (packages/rxjs/src/internal/MySubject.ts)
2. Implement next(), error(), complete() methods and value storage/replay logic specific to your variant (packages/rxjs/src/internal/MySubject.ts)
3. Export from main index.ts alongside BehaviorSubject, ReplaySubject, and AsyncSubject (packages/rxjs/src/index.ts)
4. Add comprehensive tests for subscription ordering, multicast, and state persistence (packages/rxjs/spec/subjects/MySubject-spec.ts)

• TypeScript — Provides type safety for functional composition patterns and catches operator misuse at compile time.
• Monorepo (Yarn Workspaces) — Enables separate packages (rxjs, ajax, fetch) with distinct export surfaces while maintaining single source of truth.
• Schedulers (async/asap/animationFrame) — Decouples observable execution timing from definition, enabling control over synchronous vs. deferred emission.
• Observer Pattern + Functional Composition — Observables implement observer contract while operators as higher-order functions enable declarative, chainable transformations.

• Lazy evaluation with cold observables by default

  • Why: Simplifies reasoning and avoids unwanted side effects, but requires explicit Subject or shareReplay() for hot behavior.
  • Consequence: Each subscription creates independent execution paths; must use multicasting operators to share upstream work.

• Synchronous by default unless scheduler specified

  • Why: Predictable execution order and debugging, but developers must explicitly use asyncScheduler or async operators for non-blocking.
  • Consequence: Long-running synchronous chains block the event loop; requires developer discipline to use proper schedulers.

• No built-in cancellation; relies on unsubscribe() and cleanup

  • Why: Avoids native Promise/async-await coupling, but places cleanup burden on subscribers and operators.
  • Consequence: Memory leaks possible if subscriptions not properly managed; requires careful subscription tracking in applications.

• Separate @see{operators} package tree from core Observable

  • Why: Allows tree-shaking and smaller bundle sizes for minimal use cases, but requires explicit imports.
  • Consequence: More verbose API surface; common operators not auto-available without explicit pipe() usage and imports.

• This is not a state management library; it does not provide persistence or distributed synchronization.
• RxJS does not replace Promise semantics; it complements them but does not implement Promise/A+ standards.
• Not intended for real-time bidirectional communication without explicit WebSocket or Socket.io integration.
• Does not provide built-in authentication, authorization, or security enforcement.
• Not a replacement for async/await or callback-based event handling in simple single-observable scenarios.

• Subscribing inside subscribe (subscription hell) (High) — Operator implementations (mergeMap, concatMap without proper flattening): Nested subscribe() calls in operator logic create hard-to-debug chains and prevent proper error propagation.
• Not unsubscribing from inner observables — packages/rxjs/src/internal/operators/mergeMap.ts, exhaustMap.ts: If inner subscriptions

1. Yarn workspace requirement: The codebase uses Yarn (not npm) due to hoisting issues with @types/jasmine vs @types/mocha; npm install will fail or produce incorrect behavior. 2. Scheduler execution context: Operators behave differently depending on which Scheduler they use (asyncScheduler vs immediate); tests may pass locally but fail in real async environments without understanding this. 3. Master vs 7.x branches: master is v8 (breaking API changes, API simplification), 7.x is stable production; PRs should target master by default, but check branch expectations. 4. Observable laziness: Observables are lazy and cold by default (re-run for each subscriber); only Subjects and multicasting operators create hot sources—a common source of confusion. 5. Monorepo test scoping: Running yarn test from root won't work; must use yarn workspace rxjs test to run RxJS tests (root runs docs tests).

• Cold vs. Hot Observables — Determines whether a source re-executes for each subscriber (cold, lazy) or shares state across subscribers (hot, eager); the root cause of many RxJS bugs where tests pass but production code fails.
• Marble Testing / Marble Diagrams — RxJS uses marble notation (time-axis ASCII art) to visualize async streams in tests; understanding marbles is essential to reading and writing RxJS test suites (see jasmine-marbles in the codebase).
• Scheduler Abstraction — RxJS Schedulers control when and on which event loop an Observable emits (sync, async, animationFrame, or custom); without understanding schedulers, timing-dependent operators (debounce, delay, throttle) are unpredictable.
• Backpressure / Demand-driven Execution — RxJS's push-based model means subscribers declare demand via Subscription; operators like buffer and throttle manage backpressure to prevent memory overflow in fast-producer scenarios.
• Subject and Multicasting — Subject is both an Observer and an Observable, enabling hot-source creation and multicasting; variants like ReplaySubject, BehaviorSubject, and AsyncSubject provide different replay semantics.
• Operator Composition via Pipe — RxJS's functional composition model (observable.pipe(op1, op2, op3)) relies on higher-order functions and function composition; understanding this pattern is key to writing maintainable reactive code.
• Memory Leaks via Unhandled Subscriptions — Forgetting to unsubscribe or improperly manage Subscription teardown is the #1 cause of memory leaks in RxJS apps; understanding subscription lifecycle and takeUntil/async pipe is critical.

• ReactiveX/RxJava — Original Reactive Extensions implementation for Java; defines the reactive programming model and operators that RxJS is based on—useful for understanding design intent.
• tc39/proposal-observable — TC39 stage-1 proposal to add Observable to the JavaScript standard library; RxJS's Observable informed this proposal and maintains compatibility with its semantics.
• angular/angular — Angular's reactive forms, HTTP client, and change detection are built on RxJS; understanding how Angular uses Observables is critical for most production RxJS users.
• ngrx/store — Redux-inspired state management library for Angular built on RxJS; common pattern in Angular apps combining RxJS streams with Redux slices.
• mobx/mobx — Alternative reactive state management library for JavaScript; often compared to RxJS for similar use cases but with different API and execution model.

• Add missing marble tests for edge cases in packages/rxjs/src/internal/operators/ (e.g., unsubscription timing in auditTime, buffer overflow in bufferCount with maxBufferSize=0). Choose an operator with incomplete test coverage and add a marble-test suite case.: Low-risk, self-contained, improves test reliability and teaches marble testing syntax (RxJS's testing utility).
• Document TypeScript generics and type inference for custom operators in the docs app (apps/rxjs.dev/). Many contributors struggle with how Observable<T> flows through pipe(operator1, operator2) due to missing type examples.: High-impact for DX, doesn't require deep RxJS internals knowledge, improves onboarding for TS users.
• Add missing exports or re-exports in packages/rxjs/src/index.ts for deprecated v7 observable factories or operators that v7 users expect but v8 has removed or renamed (e.g., combineLatest overload signatures).: Helps with v7→v8 migration tooling, is purely additive (no risk of breaking changes), and is clearly scoped in a single file.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub