GO — Healthy across the board

• Last commit 3d ago
• 24+ active contributors
• Distributed ownership (top contributor 33% of recent commits)
• MIT licensed
• CI configured
• Tests present

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

MobX is a lightweight, battle-tested reactive state management library for JavaScript/TypeScript that automatically tracks observable state changes and reruns derivations (computed values, reactions, renders) when data mutates. It solves the complexity of manual subscription management and fine-grained reactivity without requiring immutability, diffing algorithms, or boilerplate reducers—state mutations automatically propagate to dependent computations. Monorepo using npm workspaces: packages/mobx is the core reactive runtime; packages/mobx-react and packages/mobx-react-lite provide React bindings; packages/eslint-plugin-mobx enforces best practices; packages/mobx-undecorate handles legacy decorator syntax. Docs live in /docs with Markdown guides and examples; website is a separate Next.js app in /website. GitHub Actions workflows in .github/workflows/ automate build, test, and release.

Frontend developers (especially React, Vue, Angular) who need predictable, scalable state management without Redux/Zustand boilerplate; teams building complex UI with deeply nested state trees, real-time data synchronization, or performance-critical renders where fine-grained reactivity matters.

Highly mature and production-ready: the project has been active since ~2015 with 28k+ GitHub stars, comprehensive TypeScript support (828k LOC TS), full CI/CD via GitHub Actions (build_and_test.yml, release.yml, coveralls.yml), extensive test coverage infrastructure, and is used by Coinbase, Canva, Guilded and other major companies. Active monorepo with 5 maintained packages (mobx, mobx-react, mobx-react-lite, mobx-undecorate, eslint-plugin-mobx).

Low risk for stable use but moderate ongoing maintenance needs: the core library is stable but the ecosystem spans 5 interdependent packages requiring coordinated releases via changesets (see .changeset/). Minor risk from single/small core team (though well-organized with GitHub Discussions for community input). Breaking changes are tracked in docs/ and changesets, with a clear release workflow. Dependency set is lean (TypeScript 5.9.2, Jest 30.3.0), minimizing supply-chain risk.

Active development with recent fixes tracked in .changeset/fix-minified-error-link.md and organized release cycle via changesets. Monorepo dependencies on Jest 30.3.0 and TypeScript 5.9.2 are kept current. PR templates and issue templates (bug.md, documentation.md) indicate ongoing community engagement. No breaking changes visible in changeset folder suggests stable maintenance mode with incremental improvements.

git clone https://github.com/mobxjs/mobx.git
cd mobx
npm install
npm test
npm run build

Daily commands:

npm run test          # Run full Jest suite
npm run build         # Build all workspaces
npm run lint          # ESLint check all packages
npm run prettier      # Auto-format TS/JS/MD
npm run docs:start    # Start local documentation site

• packages/mobx/src: Core reactive engine containing observable, computed, reaction, and action implementations—the heart of MobX's dependency tracking
• packages/mobx-react-lite/src: Minimal React integration (observer HOC, useLocalObservable hook) for functional components; the recommended React binding
• packages/mobx-react/src: Full-featured React class & function component integration with lifecycle hooks and context support; legacy but feature-complete
• .github/workflows/build_and_test.yml: CI pipeline definition ensuring all commits are tested against Node.js and TypeScript versions
• .changeset: Semantic versioning and changelog management using changesets; required review for public API changes
• docs/api.md: Primary API documentation; start here to understand observable(), computed(), reaction(), and action() contracts

Start in packages/mobx/src/ for core reactive engine changes (observable.ts, reaction.ts, computed.ts patterns). For React integration, edit packages/mobx-react-lite/src/ (hooks) or packages/mobx-react/src/ (class components). Tests mirror source structure: tests/ folders. Documentation updates go in /docs/*.md. Use 'npm run mobx test' or 'npm run mobx-react test' to isolate workspace testing.

No required environment variables for basic development. Monorepo workspace commands require npm v7+ (check 'npm -v'). TypeScript strict mode is enforced (see tsconfig in packages/mobx)—migrations from loose typings will require explicit type assertions. Decorator syntax (mobx-undecorate) requires legacy TS/Babel setup and is no longer the primary API. Building documentation requires Node.js and the website/ subfolder's separate npm setup (run 'npm prepare' once). Jest coverage thresholds may block commits if tests drop below configured percentages.

• Reactive Programming / Observable Pattern — MobX's entire architecture depends on automatic dependency tracking between observables and their consumers—understanding push-based reactivity vs. pull-based state queries is essential
• Transparent Reactivity / Autorun Mechanics — MobX automatically tracks which observables are accessed during reaction/computed/render execution—misconceptions about 'when tracking happens' cause most user bugs
• Fine-Grained Reactivity / Granular Subscriptions — Unlike Redux, MobX only reruns derivations whose inputs actually changed, enabling precise control and performance optimization without memoization boilerplate
• Computed Properties / Lazy Evaluation — MobX's computed() runs only when accessed AND its dependencies changed; understanding caching and cache invalidation prevents performance regressions
• Action Batching / Transaction Semantics — MobX's action() wrapper groups mutations and defers notifications; misuse leads to unexpected intermediate states and waterfall rerenders
• Proxy-Based Object Interception — MobX uses JavaScript Proxies to transparently intercept property reads/writes on observables—this enables zero-boilerplate reactivity but creates edge cases (JSON stringify, spreading)
• Dependency Graph Tracking — MobX maintains an internal directed acyclic graph of dependencies; understanding when nodes are marked dirty and topological recomputation order helps debug complex state interactions

• reduxjs/redux — Alternative state management with explicit reducers/actions; MobX's main competitor for same problem space with opposite philosophy (immutable vs. reactive)
• pmndrs/zustand — Lightweight alternative offering minimal boilerplate; smaller API surface but less automatic tracking than MobX's reactive model
• preactjs/preact — Lightweight React alternative; MobX works seamlessly with Preact and shares the same observer pattern for component integration
• mobxjs/mobx-state-tree — First-party companion library building on MobX core to add type-safe tree structure and middleware (snapshots, patches, time-travel)
• react/react — Primary framework target; MobX integrates deeply via packages/mobx-react and packages/mobx-react-lite for automatic component tracking

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for mobx-react and mobx-react-lite interoperability

The repo has two React integration packages (mobx-react and mobx-react-lite) but there's no dedicated test suite validating they work correctly together or against the same mobx core. This would catch regressions when core mobx changes affect React bindings differently.

• [ ] Create packages/mobx-react/tests/mobx-react-lite-compat.test.tsx to test shared observer behavior
• [ ] Add tests validating computed/observable changes propagate identically in both libraries
• [ ] Add tests for edge cases like mixing Provider from mobx-react with observer from mobx-react-lite
• [ ] Update .github/workflows/build_and_test.yml to run these integration tests on every push

Add automated bundle size regression detection for all packages

While test:size script exists in workspace scripts, there's no CI workflow enforcing bundle size limits. With multiple packages (mobx, mobx-react, mobx-react-lite, eslint-plugin-mobx), unintended bloat can slip through. This prevents size regressions on PRs.

• [ ] Create .github/workflows/bundle-size-check.yml that runs 'npm run test:size --workspaces' on PRs
• [ ] Add size limits in packages/mobx/package.json, packages/mobx-react/package.json, packages/mobx-react-lite/package.json
• [ ] Configure workflow to comment on PRs with size comparisons (delta vs main branch)
• [ ] Update CONTRIBUTING.md with bundle size expectations

Add TypeScript strict mode validation and JSDoc coverage for packages/mobx/src

The eslintrc.js suggests TS support but there's no evidence of strict mode enforcement across the core mobx package. Adding strict mode checks and measuring JSDoc coverage ensures core APIs are well-typed for consumers, especially important for a state management library with public API.

• [ ] Add tsconfig.strict.json with strict: true to packages/mobx/
• [ ] Run 'tsc --noEmit -p packages/mobx/tsconfig.strict.json' in a new GitHub Action
• [ ] Add eslint rule 'jsdoc/require-jsdoc' for packages/mobx/src to enforce public API documentation
• [ ] Update .github/workflows/build_and_test.yml to include strict type checking step

• Add TypeScript strict null check tests to packages/mobx/tests/ for edge cases in observable() with undefined values—currently sparse coverage for null-safety patterns
• Expand docs/api.md with before/after code examples for migration from Zustand to MobX for React developers—currently missing comparative guide for common use case
• Create a runnable example in packages/mobx/examples/ demonstrating the Observer pattern with computed properties chained 3+ levels deep, including performance benchmarking—none currently exist in file list

The MobX repository demonstrates reasonable baseline security practices with automated CI/CD workflows and dependency management tools (Dependabot) in place. However, the security posture is weakened by a permissive security policy that lacks commitment to timely fixes, inadequate vulnerability reporting infrastructure, and potential version management issues. The project would benefit from a more formal security disclosure process, expanded version support policy, and stricter dependency version management. No critical hardcoded secrets, injection vulnerabilities, or Docker/infrastructure misconfigurations were identified in the provided file structure.

• Medium · Security Policy Lacks Commitment — SECURITY.md. The SECURITY.md file states that packages are provided 'as-is without guarantees or SLAs' and security issues will not be back-ported. This could delay security fixes for users on non-latest versions and creates uncertainty around vulnerability response timelines. Fix: Establish a clear security policy with defined response times, support for at least one previous major version, and a structured vulnerability disclosure process with estimated patch timelines.
• Medium · Single Point of Contact for Security Reports — SECURITY.md. Security vulnerabilities are reported to a personal email (info@michel.codes) rather than a dedicated security reporting channel or bug bounty platform. This lacks transparency and formal tracking mechanisms. Fix: Use a dedicated security reporting channel (e.g., security@mobxjs.org) or integrate with a vulnerability disclosure platform. Consider implementing a responsible disclosure policy with public acknowledgment process.
• Low · Incomplete Dependency Information — package.json. The package.json snippet provided is truncated and does not show the complete list of dependencies. This makes it impossible to fully audit for known vulnerabilities in transitive dependencies. Fix: Maintain an up-to-date package-lock.json or yarn.lock, use tools like 'npm audit' regularly, and configure Dependabot (already present in workflows) to automatically scan and alert on vulnerable dependencies.
• Low · Jest Version Override Specification — package.json - overrides section. The root package.json specifies 'jest': '^30.3.0' in overrides, which appears to be a typo (Jest v30 doesn't exist). This could indicate version management issues and potential use of incorrect/vulnerable versions. Fix: Correct the Jest version to a valid release (e.g., '^29.0.0' or '^30.0.0' if it exists). Implement version pinning strategies and automated dependency update reviews.

LLM-derived; treat as a starting point, not a security audit.

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

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/mobxjs/mobx shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live mobxjs/mobx repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/mobxjs/mobx.

What it runs against: a local clone of mobxjs/mobx — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in mobxjs/mobx | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of mobxjs/mobx. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/mobxjs/mobx.git
#   cd mobx
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of mobxjs/mobx and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "mobxjs/mobx(\\.git)?\\b" \\
  && ok "origin remote is mobxjs/mobx" \\
  || miss "origin remote is not mobxjs/mobx (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 33 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/mobxjs/mobx"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.