Static sample preview

Create React App stability-signal probe

Repo: react/create-react-app

Assessment: Stale-trust / library-package choice

This Stability-Signal Probe sample shows how a FoldEngine report can distinguish popularity and familiarity from present stability. It is based on public React and GitHub evidence, not private work or a live backend response.

Question

Can a highly familiar public repo still carry stale stability signals after its ecosystem moves on?

Target surface

Product/surface: Create React App as a React app-starting toolchain choice. The decision is whether popularity, tutorials, and familiarity still support adoption after the maintainer guidance changed.

Short finding

Create React App looked stable through popularity, tutorials, years of adoption, and a simple beginner command. React's own 2025 guidance now frames it as deprecated for new apps and points teams toward frameworks or modern build tools.

What FoldEngine checked

  • React's public deprecation and migration guidance for Create React App.
  • The public GitHub repository and visible popularity/fork familiarity signal.
  • React 19 breakage discussion in the public issue tracker.
  • Documentation drift: older tutorials and references still pointing to a project whose recommended role changed.

What FoldEngine did not check

  • Private applications built with Create React App.
  • Repository code execution.
  • Maintainer intent or blame.
  • Full migration planning for any specific application.
  • Security audit or dependency vulnerability review.

Evidence boundary / receipt-style summary

Artifact kind
stability_signal_probe
Evidence surface
Public React guidance and public GitHub issue evidence
Private access
None
Execution
No repo code execution

Seed candidates

Bounded change proposals extracted from the probe evidence.

Seed A — Classify migration path per app

Hypothesis: Each CRA-based app needs a specific migration target (framework vs. build tool) based on its type.

Value: high · Risk: low

Evidence required: App type classification (SPA, SSR, static) documented per project.

Verification: Each app has a documented migration target with justification.

Seed B — Add deprecation notice to README

Hypothesis: Explicit deprecation notices prevent new developers from treating CRA as the recommended starting point.

Value: medium · Risk: low

Evidence required: README updated with migration context and recommended alternatives.

Verification: README references React's current guidance and names a migration path.

Decision receipt: HOLD

Do not start new projects on Create React App. Existing CRA projects should be classified for migration priority before investing in maintenance.

Decision
Hold
Expires
30 days from issuance, unless superseded by a closure check

What must change:

  • Migration path classified per app
  • Deprecation context added to documentation

Governed next steps

  1. Priority 1 — Seed A: Classify migration path

    Unlock: Inventory of CRA-based projects available.

    Exit: Each project has a documented migration target.

  2. Priority 2 — Seed B: Deprecation notice

    Unlock: Migration targets decided (Seed A).

    Exit: README updated with current React guidance and migration path.