React Laravel Package

Product Decisions This Supports

• Build vs. buy vs. write-50-lines: This package answers a narrow question — "can we get JSX syntax transformed inside a PHP codebase without Node in production?" — and it answers it with a thin MIT wrapper around Babel plus a pure-PHP fallback. The real decision it informs is whether that capability is worth a dependency at all, versus a compile-time build step or a small in-house transpile helper.
• Feature feasibility for shared UI: Useful for evaluating a design-system reuse story in a Laravel monolith — e.g., authoring React components once and reusing the markup for transactional emails, PDF invoices, admin exports, or Blade partials that can't go through a Node asset pipeline.
• Deployment topology: Directly relevant if your roadmap includes "no Node in production" (locked-down hosts, shared hosting, air-gapped environments, compliance-restricted build agents). The fallback mechanism is the entire value proposition — a decision on whether runtime transpilation is acceptable at all.
• Incremental React adoption: Supports a phased migration from Blade/jQuery by letting teams introduce JSX syntax without committing to a full Vite/Webpack pipeline on day one.
• Dependency-risk policy: A useful test case for your "unmaintained package" policy — 5 stars, zero dependents, last release January 2019, low opportunity score. Whatever you decide here becomes precedent for a dozen similar calls.

Important caveat for scoping: this is a transformer, not a renderer. It converts JSX into React.createElement calls (via Babel, or the PHP fallback). It does not execute React, does not server-render components to HTML, and does not give you hooks/context SSR. Any feature spec that assumes "render React from PHP" is only satisfiable if you pair it with a JS runtime (V8js extension, a Node sidecar, or a headless browser). Verify this in a spike before it lands on a roadmap.

When to Consider This Package

Consider it when:

• Node genuinely cannot exist in the target environment, and the transformation target is a non-hot path — scheduled jobs, email rendering, one-off document generation, CLI tooling.
• Volume is low enough that per-invocation transpilation cost is irrelevant; the fallback path is exercised rarely.
• You are willing to vendor or fork it. Treat it as sample code, not a maintained dependency: no releases since 2019 means no React 17+ automatic JSX runtime, no TypeScript, no ESM, and no security patching.
• The output feeds a browser or a separate JS-aware process anyway, so a transpile-only step is actually what you need.

Look elsewhere when:

• The transform sits on a request path. Shelling out to node/Babel or parsing JSX in PHP per request is a latency and reliability anti-pattern.
• You need actual server-side rendering of components to HTML — use a Node SSR service, spatie/laravel-server-side-rendering-style approaches, Inertia, or Livewire instead.
• You want a modern toolchain: hot reload, tree-shaking, TypeScript, the automatic JSX runtime, React 18/19 features. This package predates all of it.
• You have any Node available at build time — then a normal Vite/laravel-vite-plugin build is strictly better and cheaper to own.
• You need long-term support, a CVE response path, or a vendor who will answer an email in 2026.

How to Pitch It (Stakeholders)

To executives: A small, free, MIT-licensed utility that lets our PHP application work with React-style markup even where we can't run Node in production. It's low cost to trial and low blast radius. The catch is that it's a one-person project, last shipped in 2019, with no user base — so the honest framing is "a two-week spike to validate the approach," not "a platform decision." If the spike succeeds, budget a small amount of engineering to own the code rather than depend on it.

To engineering: It's a wrapper: shell out to Babel with the React JSX transform plugin, fall back to a pure-PHP transformer if Node isn't present. Small surface area, easy to read, easy to replace. Two things to flag: (1) it transpiles JSX, it does not render React — you still need a JS runtime to get HTML out; (2) no support for the React 17+ automatic runtime or TypeScript. Recommendation: spike it behind an interface, measure the fallback path's output fidelity on our real components, and assume we fork it if we keep it. If the spike shows our only real need is compiling JSX to JS strings, we can likely reimplement that in a day and skip the dependency entirely.

Bottom line for the decision meeting: Do not adopt as a strategic dependency. Evaluate as a time-boxed prototype for the specific "no Node in production" constraint — and only if that constraint is real rather than assumed.