Inertia Bundle Laravel Package

Technical Evaluation

Architecture fit — the premise needs correcting. This is not a Laravel package. creativspeed/inertia-bundle is a Symfony bundle (built on the AbstractBundle pattern, Symfony 6.1+) that targets Symfony 8.0+ / PHP 8.2+. In a Laravel codebase it is not installable in any meaningful sense: Laravel already ships a first-party, actively maintained adapter (inertiajs/inertia-laravel) that is the correct choice by default. The bundle's architecture fit is therefore zero for our Laravel estate and conditional for any Symfony services we own (acquired apps, internal admin tools, or a service split that landed on Symfony). The one genuinely portable asset is the frontend contract: createInertiaApp, page-component resolution, and Vite entry setup are server-agnostic, so our Vue/React conventions, component library, and useForm patterns carry over unchanged.

Integration feasibility. Ceremony is low: Composer install, Flex auto-registration, a config/packages/inertia.yaml, one Twig root template, and InertiaInterface injected into controllers. The API surface is small and legible (render, share, redirect, back, location, defer, merge, deepMerge, encryptHistory, clearHistory), and the testing helper (assertInertia) is the kind of thing that determines whether a team actually writes tests. Nothing here requires an API layer, a token scheme, or a serializer — that is Inertia's whole value proposition and this bundle does not fight it.

Technical risk — this is where the package fails a TPM screen.

• Adoption signal is absent. 0 stars, 0 dependents, score ~18/100. No evidence anyone runs this in production.
• Bus factor of one. Single maintainer, single email contact, no visible security policy, no governance, no CI/coverage badges.
• Documentation and release drift. Changelog enumerates only 1.0.0 while release notes exist for v1.1.0 and v2.0; the README advertises the "Inertia.js v2 protocol" while the v2.0 note claims "Inertia.js v3 protocol"; the install snippet says ^2.0 in one place and ^1.0 elsewhere. For a protocol-coupled library, that ambiguity is a real defect — client/server protocol mismatch produces silent partial-reload and deferred-prop failures rather than loud errors.
• Bleeding-edge target. "Symfony 8.0+ (also compatible with 7.0+)" means we would be tracking two fast-moving releases simultaneously.
• Release date anomaly. Last release stamped 2026-09-04 — either metadata noise or a signal our vendor feed is unreliable; either way, do not treat it as evidence of active maintenance.

Key questions to answer before spending any TPM time. (1) Do we own or plan to own any Symfony services at all? If no, close this out. (2) Who forks and owns the bundle if the maintainer disappears, and is that person on the Symfony team or the frontend team? (3) What does ^1.0 → ^1.1 → ^2.0 actually break, and is there a migration guide? (4) Is there a test suite behind composer test, and does it run in CI? (5) How does SSR behave when 127.0.0.1:13714 is down — graceful client-side fallback or white screen? (6) Are shared auth/flash values scoped per-request or per-container, and could one user's flash leak to another?

Integration Approach

Stack fit. Treat this as a Symfony-only option, not a Laravel one. For Laravel work, standardize on inertiajs/inertia-laravel and treat this bundle purely as a reference implementation for protocol semantics (303 redirect conversion, asset-version conflict handling, deferred prop groups). If a Symfony service enters the estate, this bundle becomes a credible candidate precisely because it does not force us to build a JSON API and re-train the frontend team.

Migration path. Do not migrate anything to Symfony to use this. The only defensible path is: an existing Symfony app needs an SPA shell → evaluate this bundle inside that app. If no such app exists, the correct decision is "no action," and the secondary value is harvesting its patterns into our own internal guidance.

Compatibility. Pin explicitly to ^2.0 and verify the resolved constraint against the README's conflicting ^1.0 example. Lock the @inertiajs/vue3 (or React) client version in the same PR that locks the PHP side — protocol version is a joint constraint, not a backend one. Confirm PHP 8.2–8.4 against our runtime images and confirm the Symfony version against our actual LTS posture, not the bundle's headline claim.

Sequencing.

1. Confirm Symfony footprint (a one-hour answer, and a hard gate).
2. Two-day spike on a throwaway Symfony 8 app: render one page, one partial reload, one deferred prop group, one merge prop, SSR off.
3. Turn SSR on behind a supervised Node process; deliberately kill it and record the failure mode.
4. Wire InertiaAuthUserInterface so the User entity controls shared payload — do not let the bundle guess.
5. Bring assertInertia into CI so the adapter is covered by tests we own.
6. Vendor/decide before production: adopt upstream with a fork-on-demand plan, or fork immediately.

Operational Impact

Maintenance. Assume we are the maintainers. The fork-and-vendor contingency is not optional at 0 dependents and a bus factor of one; MIT licensing makes it legally clean, but it converts a dependency into a headcount commitment. Budget recurring time for Symfony major-version tracking, since the bundle deliberately rides the newest release.

Support. GitHub Issues plus a personal email, no SLA, no CVE process, no published support window. For anything customer-facing or handling auth, that is below our third-party risk bar without an internal owner and a pinned version.

Scaling. The PHP side is stateless and scales like any Symfony app under PHP-FPM — no new concern. SSR introduces a stateful Node process per environment: memory growth, cold starts, port allocation in multi-tenant or containerized setups, and a health check that must be wired into deploy and rollback. That process is the actual operational delta and should be costed as such.

Failure modes to instrument. SSR server unreachable → verify client-side fallback; asset-version mismatch loops (the bundle claims to handle this — test it); 302→303 conversion against older clients; deferred prop groups that silently never resolve; flash/validation-error sharing leaking across requests if state is container-scoped; Twig escaping of page|json_encode|e('html_attr'), which is an XSS boundary and deserves a test rather than a code review.

Ramp-up. Frontend engineers transfer almost fully — Inertia concepts, Vite, and page components are identical to our Laravel work; only the server-side idiom changes. Symfony engineers need a short ramp on Twig root views and bundle config. Realistic TPM estimate: one engineer-week for the spike and decision memo, plus roughly 20% of one engineer ongoing if adopted. Recommendation: do not adopt for Laravel work; hold as a conditional option for Symfony services, gated on question (1).