Inertia pages edit like Vite source, because that is what they are

Because its pages are not Blade. An Inertia route renders a Vue, React or Svelte component compiled by Vite, and PortBay launches that dev server itself — so it can add source-location stamping from outside your repo, exactly as it does for any other Vite project. Blade renders on the server, where there is no such seam, which is why the other two lanes in the Laravel family behave differently.

No. Nothing goes into composer.json and nothing goes into package.json. The stamping plugin ships inside the PortBay app and reaches Vite through a generated config that imports and spreads your own, kept in PortBay's data directory. Uninstall PortBay and both manifests, your lockfiles and your vite.config are byte-for-byte what they were.

PortBay identifies the Laravel family from a composer.json plus an artisan file, then checks composer.json for inertiajs/inertia-laravel before checking anything else in that family. That order is deliberate: a project carrying both Inertia and Livewire is treated as Inertia, because that is the lane with the better capability rather than the one that happens to be alphabetically first.

Into the page component, not into a Blade view. PortBay resolves the route through routes/web.php to the Inertia page name the action passed — Inertia::render('About') gives About — then to the component file behind that name, and writes an Inertia Head element there. If the component has no Head yet, one is created and the import is added, rather than the field being reported as locked. Before that adapter existed, this entire lane refused Inertia projects.

In one respect, yes. .vue and .svelte are markup-first formats, so a component usage carries its own coordinate and an element rendered by one of your components still traces back to where you used it. .jsx and .tsx are script-first: host elements are stamped but component usages are not, because a capitalised tag there can be a TypeScript generic parameter list. The practical difference is markup produced by a library you did not author, which has no coordinate on a React page.

Yes, on the other lane. app.blade.php is a server-rendered template with no source stamping, so edits there are resolved by finding your markup in the file rather than by following a coordinate — which means text, class and attribute edits write, and structural edits are refused rather than guessed. In practice the shell is a handful of lines you rarely touch, and everything you do touch is in the page components.

No. It is a PortBay Pro feature, still in early access behind an opt-in toggle in Settings, and it is not compiled into the open-source build. It refuses to run while the project is shared over a public tunnel, and the edit bar works only on local .test hosts. Running an Inertia app on a real .test domain with trusted HTTPS, PHP-FPM and a managed database is in the free app.

Yes, on the page-component side. JSX, TSX and Vue are among the four formats where that structural edit is supported, so an element in a page component can be moved into a new component file, with the import added and the original span replaced by the tag. A span carrying a template expression is refused by name, because the values it uses are locals of the page and would not exist in the new file. The Blade shell does not get this: extraction is refused there rather than half-written, because a component means something different in a PHP template.