Tomato Splade Laravel Package

Technical Evaluation

Architecture fit. tomatophp/tomato-splade is a maintained fork of Laravel Splade packaged under the TomatoPHP umbrella. It preserves Splade's central proposition: developers author Blade templates and the package compiles them into Vue 3 + Inertia behavior, delivering SPA-style navigation without the team hand-writing Vue single-file components day to day. For a backend-heavy Laravel team building internal admin panels, CRUD screens, dashboards, and back-office workflows, that is a strong architectural fit and a genuine velocity lever. It is a poor fit for public, SEO-critical marketing surfaces (Splade's SSR story is thin), for teams standardized on React/Next.js or Livewire, and for standalone Laravel apps that are not otherwise buying into TomatoPHP conventions—those teams get marginal value over upstream protonemedia/laravel-splade. The TPM framing should be "Blade-first SPA accelerator for internal tooling," not a frontend platform bet. The fork's added value is the curated TomatoPHP components and "selected updates": real, but narrow.

Integration feasibility. Nominally this is composer require plus splade:install, middleware registration, and vendor publishing. The actual integration surface is larger: Node/Vite, Tailwind, Inertia, Blade component registration, and the surrounding TomatoPHP dependency graph. With 2 stars, 0 dependents, and a last release of 2024-04-29, there are effectively no reference implementations, no integration write-ups, and no third-party coverage to de-risk the work. Integration knowledge must be derived by reading source and diffing against upstream Splade. A TPM should gate commitment on a short spike that confirms the real Laravel/PHP/Inertia/Vite/Node version matrix, verifies whether the package replaces or conflicts with upstream protonemedia/laravel-splade (duplicate service providers and Blade registration are the classic failure here), and measures setup plus build-pipeline effort before roadmap capacity is allocated.

Technical risk. Highest-risk dimension, and three risks compound. Fork divergence: the fork's delta from upstream is undocumented, so upstream security and bug fixes must be cherry-picked manually with unknown conflict cost. Low adoption: effectively unaudited code, including a JS bundle and server-side compile helpers that represent meaningful attack surface. Single-maintainer supply chain: no SLA, no commercial escalation path, and a last release that predates recent Laravel minors, so upgrade compatibility is unproven. Product risk follows directly—the organization may inherit a thin fork with no upstream lifeline, and exit cost grows as fork-specific components spread across the codebase.

Key questions.

• Is the organization deliberately committing to the TomatoPHP admin stack, or is this a one-off experiment?
• Which Laravel, PHP, Inertia, Vite, and Node versions are actually supported—is there a written compatibility matrix anywhere?
• How far has the fork diverged from upstream Laravel Splade, and can upstream patches be applied cleanly?
• Who is the accountable engineering steward, what is the bus factor, and is there any commercial support path via TomatoPHP?
• Are upstream MIT attribution and notices preserved in the fork?
• What is the exit cost in 12–18 months if the fork is abandoned, blocked on a Laravel major, or superseded by upstream Splade or an in-house library?
• Which measurable product outcome justifies adoption: faster internal-tool delivery, reduced frontend boilerplate, or ecosystem consolidation?

Integration Approach

Stack fit. The package assumes Laravel, Blade, a Node/Vite build, Tailwind, and Inertia, and it presumes TomatoPHP admin conventions. For a Laravel + Blade application, this is a natural progression. For an API-first app with a separate React/Vue SPA, it introduces a second rendering paradigm and should be rejected. Position the decision as a rendering-layer choice for internal tooling, not a frontend architecture replacement.

Migration path. Greenfield adoption is cheapest—use it as the rendering layer for new admin modules. Brownfield adoption should be progressive and route-scoped, since Splade can SPA-ify individual routes; wrap the lowest-risk pages first. Plan the exit before the first commit: auto-generated and Tomato-specific components are expensive to port out, so isolate them behind the application's own layout and wrapper components rather than calling fork-specific components directly throughout the codebase. That single discipline keeps a future swap to upstream Splade or an in-house library economically plausible.

Compatibility. Pin Laravel minors, PHP, Node/Vite majors, and Inertia majors explicitly. Run composer why-not and npm audit in CI. Treat the package as vendored: mirror it internally or fork it to a private repository so a Packagist disappearance or an unreviewed release cannot break the build. Explicitly verify the relationship to upstream protonemedia/laravel-splade before writing feature code against it.

Sequencing.

1. Spike one representative admin page in a throwaway repo; measure setup time, build time, bundle size, and time-to-interactive.
2. Audit dependencies and quantify divergence from upstream Laravel Splade.
3. Hold a recorded decision gate: upstream Splade vs. this fork vs. standard Inertia + Vue, with rationale.
4. If the fork wins, create an internal mirror and pin all versions.
5. Pilot a single low-risk admin module behind a feature flag.
6. Document the maintenance playbook: upstream tracking cadence, security patch procedure, upgrade ownership.
7. Expand to further modules only after a stability window and a go/no-go review.

Attach success metrics to the pilot before approving broader adoption: delivery time for the first module, bundle size, build reliability, number of fork-specific patches required, and engineering hours spent on setup and support.

Operational Impact

Maintenance. The dominant lifetime cost. Adopting this means owning a two-star fork with zero downstream dependents. Assign one named engineer as steward, even part-time. Recurring work includes upstream diffing, security patching, JS dependency churn, and Vue/Inertia major upgrades. Without a steward the fork will silently rot against Laravel releases and the application inherits an upgrade freeze.

Support. Effectively no community: issues on a two-star repository are rarely triaged, and Stack Overflow coverage is thin. Support is self-support plus whatever the broader TomatoPHP ecosystem offers—verify Discord or commercial terms before relying on them. Escalation is directly to the maintainer with no SLA. Set stakeholder expectations explicitly: this is not a vendor-supported dependency.

Scaling. Splade's compiled components can produce larger bundles and less efficient rendering than hand-written Vue, so benchmark bundle size and interactivity on realistic admin pages before scaling to large surfaces. Keep public, SEO-critical pages off this stack. Team scaling is also constrained—onboarding depends on reading source rather than documentation—so knowledge capture must be deliberate and scheduled, not assumed.

Failure modes.

• An upstream CVE in Laravel Splade is not backported to the fork.
• A Laravel major upgrade is blocked by fork incompatibility, freezing the application.
• Build-pipeline breakage from drifting Node/Vite/Tailwind versions with no upstream fix.
• The sole maintainer abandons the package; Packagist availability or release hygiene degrades.
• Silent conflict with upstream protonemedia/laravel-splade causes duplicate providers or broken Blade registration.
• Fork-specific components spread widely, making exit to upstream economically unviable.

Ramp-up. Expect a real but bounded learning curve: engineers must absorb Splade's Blade-to-Vue compilation model, Inertia navigation semantics, and TomatoPHP's component conventions—none of which are documented here. Budget a spike plus one pilot module of paired work with the steward, and capture findings as internal docs, because the external documentation will not carry the next engineer. Ramp-up is fastest for teams already fluent in Laravel, Vue 3, and Inertia; for everyone else, the onboarding cost should be priced into the go/no-go decision rather than discovered after standardization.