Laravellte Laravel Package

Product Decisions This Supports

• Build vs. buy for UI scaffolding and admin surfaces: The package bundles a TALL-stack (Tailwind, Alpine, Laravel, Livewire) starting point with full-page Livewire components. For internal tools, admin panels, and CRUD-heavy back-office screens, this shifts the default from "custom SPA build" toward "adopt the stack and customize," typically reducing time-to-first-demo by weeks.
• Frontend architecture direction: The v2.0 move to Livewire 2 + Alpine 2 and the removal of Turbolinks signals a deliberate bet on server-rendered, component-driven interactivity over Turbolinks/SPA navigation. This is a roadmap-level commitment: adopting it sets the pattern for how future interactive features are built.
• Feature prioritization and reuse: Extracting Livewire components out of subfolders and supporting full-page components makes components more discoverable and independently reusable. Practically, this supports breaking a large roadmap epic (e.g., a customer portal) into parallel workstreams that each own a component.
• Platform upgrade planning: v2.0 requires Laravel 8. That is a gating dependency for any roadmap item scheduled on this package — the upgrade is now coupled to a framework upgrade, which needs its own line item and risk budget.
• Roadmap timing and MVP scope: Useful where speed-to-validation matters more than bespoke UX. Less useful when differentiating frontend experience is itself the product.
• Hiring and onboarding decisions: It narrows the required skill profile to PHP/Laravel plus Livewire rather than a separate JS/SPA team — a real cost-model input for team planning and contractor sourcing.

When to Consider This Package

Adopt when:

• The product is on (or ready to move to) Laravel 8+ and the team is comfortable with Livewire 2 and Alpine 2.
• The dominant workload is forms, tables, dashboards, and server-driven interactivity — the sweet spot for full-page Livewire components.
• You are starting greenfield or have a contained surface (admin, internal tool, MVP) where a TALL-stack baseline saves real setup time.
• You value reduced JavaScript surface area for maintainability and a smaller specialist hiring pool.
• The team wants a convention-driven scaffold rather than assembling Livewire, Tailwind, and Alpine wiring from scratch.

Look elsewhere when:

• You are on Laravel 6/7 or Livewire 1 and cannot absorb a coordinated framework upgrade — v2.0 is a major bump with breaking changes (Livewire 2 migration, Turbolinks removal).
• Existing behavior depends on Turbolinks-style page transitions; removing it changes perceived navigation performance and requires re-verification of page state, scroll, and asset lifecycle behavior.
• The product needs offline-first, highly stateful, or animation-heavy client experiences where an SPA or richer client framework is the better fit.
• You require long-term vendor-neutral architecture; this package couples you to the Livewire release cadence.
• The team lacks PHP/Laravel depth — the abstraction reduces JS work but does not remove the need for strong server-side skills.

How to Pitch It (Stakeholders)

For executives: This release modernizes the package to current Laravel/Livewire generations and makes its UI components more modular. It lets us stand up internal tools, admin screens, and MVP flows with one stack instead of two, which reduces both build cost and ongoing maintenance surface. The trade-off is a one-time upgrade: v2.0 is a major version that requires Laravel 8 and drops Turbolinks, so it should be sequenced as a planned platform upgrade rather than an incidental dependency bump — with a scoped regression pass on navigation and page-state behavior.

For engineering: v2.0 is a breaking release — Laravel 8, Livewire 2, Alpine 2, Turbolinks removed. The upside is structural: full-page Livewire components and components extracted from subfolders improve reusability and make large features parallelizable across owners. Plan the migration as (1) framework/dependency upgrade, (2) Livewire 1→2 component audit, (3) Turbolinks removal with explicit testing of navigation, scroll restoration, and asset re-initialization, (4) refactor to the new component layout. Budget for the code refactor in the release notes; it is not a drop-in update.

Recommendation: Worth adopting for new work on Laravel 8+, and worth the upgrade for existing adopters who can schedule it — but treat v2.0 as a planned migration with a regression budget, not a routine version bump.