- Is rompetomp/inertia-bundle the Laravel Inertia adapter or the Symfony one?
- It is the Symfony bundle. If you are building a Laravel application, the package you want is inertiajs/inertia-laravel, which ships the middleware, root view, and config for Laravel. This bundle targets Symfony 6.x/7.x and provides the equivalent server-side adapter there. Confirm your target framework before adding it to composer.json, because the two adapters are not interchangeable.
- How do I install rompetomp/inertia-bundle in a Symfony application?
- Install it with Composer and register the bundle in config/bundles.php. You then add a root Twig template that hosts the Inertia mount point and include the matching client-side adapter for Vue, React, or Svelte in your JavaScript entry point. Finally, wire your controllers to return Inertia responses instead of Twig-rendered views. None of these steps is exotic, but plan them as one sequence rather than ad hoc.
- Which Symfony and PHP versions does this bundle support?
- It targets Symfony 6.x and 7.x on PHP 8.1 and above. Check the declared Composer constraints against your pinned Symfony version before committing, since a version mismatch is the most common reason an Inertia integration gets abandoned mid-sprint. If you are on an older Symfony release, verify support explicitly rather than assuming patch-level compatibility.
- Do I need a root Twig template for Inertia?
- Yes. Inertia renders every page through a single root template that contains the mount point plus your compiled CSS and JavaScript assets, so all subsequent pages inherit it. Keep that template minimal: a div for the app, the asset tags, and any global data the client needs. Once it exists, converting a controller action to an Inertia response requires no further template work.
- How do I share data with every Inertia page?
- Use a shared-props middleware or a base controller method so common data is resolved once, centrally, and inherited by every page. Resolving props per controller leads to duplication and drift. Introduce the shared-props layer early, before you convert more than one or two pages, so later conversions are consistent.
- How does asset versioning work with Vite or Webpack Encore?
- Inertia compares a version identifier between the server response and the loaded page, and forces a full reload when a new deploy changes it, which prevents users from running stale JavaScript against new props. You wire that version to your Vite or Encore build manifest. This step is where most first integrations stall, so assign a clear owner for the contract between the PHP build and the frontend build.
- Does this bundle support Inertia server-side rendering (SSR)?
- Client-side rendering is sufficient for most internal and admin screens, and it keeps your operational model free of an extra runtime. SSR requires a Node process running alongside PHP to render components server-side, which is a real infrastructure commitment. Decide up front whether SEO-sensitive public pages need SSR, and leave those pages on Twig until you have a reason to change.
- Can I set a custom page URL on an Inertia response?
- Yes. Version 2.4.3 adds the ability to set a custom page URL independent of the request URI, which is useful for query-string normalization, aliased or legacy routes, and shareable filter state. The API is opt-in and backwards compatible, so you can ignore it until a concrete use case appears. If you already own routing or canonicalization logic, decide who arbitrates conflicts before adopting it broadly.
- How do redirects and validation errors behave with Inertia?
- Redirects after PUT, PATCH, and DELETE requests are handled as 303 responses so the browser follows with a GET, and validation errors are flashed and delivered to the page as props rather than a full error page. That keeps form handling in your existing Symfony validation and authorization layer. History and back-button behavior are handled by the client adapter on top of the page object.
- Is it safe to depend on a single-maintainer package like this in production?
- The bundle is a thin translation layer, so the blast radius of a defect is contained and you could fork or vendor it if needed. The real risk is concentration: effectively one maintainer, patch-level releases only, and no published security policy or LTS. A pragmatic path is to adopt Inertia incrementally, starting with one low-traffic admin module, and document an exit plan if the dependency stalls.