- What is tomatophp/tomato-splade and when should I use it?
- It is a maintained fork of Laravel Splade packaged under the TomatoPHP umbrella, aimed at Blade-first SPA development for internal tooling. Use it for admin panels, CRUD screens, and back-office dashboards in Laravel apps that already follow TomatoPHP conventions. Avoid it for public SEO-critical marketing sites or for teams standardized on React, Next.js, or Livewire.
- How do I install tomatophp/tomato-splade in a Laravel application?
- The nominal path is composer require tomatophp/tomato-splade, running splade:install, registering middleware, and publishing vendor assets. In practice the integration surface is larger: you also need Node and Vite, Tailwind, Inertia, and Blade component registration working inside your TomatoPHP dependency graph. Budget time for a spike and for the build pipeline, not just the Composer install.
- Does tomatophp/tomato-splade conflict with protonemedia/laravel-splade?
- Treat upstream Splade as a conflict risk rather than a companion, because duplicate service providers and Blade component registration are the classic failure mode. This fork is a replacement for protonemedia/laravel-splade, not an add-on. Run a short spike to confirm which service providers and Blade registrations win before committing either package to a shared codebase.
- Which Laravel, PHP, Inertia, Vite, and Node versions does tomatophp/tomato-splade support?
- There is no published compatibility matrix anywhere in the repository, and the last release was 2024-04-29, which predates several recent Laravel minors. That means Laravel, PHP, Inertia, Vite, and Node support is unproven until you verify it yourself. Pin your versions and run an install-and-build spike before allocating roadmap capacity.
- How is tomatophp/tomato-splade different from upstream Laravel Splade?
- The fork's delta is the curated TomatoPHP components and selected updates, which are real but narrow. The exact diff against upstream is not documented, so upstream security and bug fixes have to be cherry-picked manually with unknown conflict cost. Confirm that the original MIT attribution and notices are preserved before you adopt it.
- Do I need to write Vue components to use tomatophp/tomato-splade?
- No, the central proposition of Splade is that you write Blade templates and the package compiles them into Vue 3 plus Inertia behavior. Backend-heavy teams get SPA-style navigation and reactive pages without authoring Vue single-file components day to day. You still own the Node, Vite, and Tailwind build, so some frontend tooling knowledge is required.
- Can I use tomatophp/tomato-splade for a public, SEO-critical website?
- No. Splade's server-side rendering story is thin, so it is a poor fit for public, SEO-critical marketing surfaces. Position it as a Blade-first SPA accelerator for internal tooling: authenticated admin panels, dashboards, and back-office workflows. If you need indexable pages, use a server-rendered or static approach instead.
- Is tomatophp/tomato-splade safe to run in production?
- Approach it with caution: adoption is very low (2 stars, 0 dependents), the code is effectively unaudited, and there is a single-maintainer supply chain with no SLA or commercial escalation path. The JS bundle and server-side compile helpers represent meaningful attack surface. Mitigate with a scoped spike, a documented exit plan, and monitoring for Laravel major upgrades.
- How do I test a Laravel app that uses tomatophp/tomato-splade?
- There are no reference implementations or integration write-ups to copy from, so you will derive the testing approach by reading the source and diffing against upstream Splade. In practice you test it like any Laravel plus Inertia app: feature tests for routes and responses, and a CI job that proves the Vite build succeeds. Add a regression test around page navigation so fork-specific behavior is caught early.
- What are the alternatives to tomatophp/tomato-splade?
- If you want the same Blade-first SPA model with broader community coverage, upstream protonemedia/laravel-splade is the closest alternative. Livewire is the natural fit if you prefer staying server-side without Inertia, and a manually wired Inertia plus Vue or React SPA works if you want full frontend control. Only pick this fork when you are deliberately buying into the TomatoPHP admin stack.