Weave Code
Hearth Laravel Package
fluid-project/hearth
Hearth is a PHP package from the Fluid Project that brings accessible, reusable UI foundations to Laravel applications. It helps teams build inclusive interfaces faster with maintainable components and sensible defaults.
A simple starter kit for the Laravel framework.
Frequently asked questions about Hearth
- What is fluid-project/hearth and what does it add to a Laravel application?
- Hearth is a PHP package from the Fluid Project that provides accessible, reusable UI foundations for Laravel applications. It is positioned as a starter kit with maintainable components and sensible defaults so teams can build inclusive interfaces faster. Technically, it is a Laravel-side library that integrates with Livewire, and its v4.1.0 release added support for Livewire v3. Treat it as a thin capability layered on top of Livewire rather than a standalone front-end framework.
- How do I install fluid-project/hearth in a Laravel app?
- Install it with Composer as you would any Laravel package, then follow the repository README for any publishing steps for configuration or assets. Because Hearth depends on Livewire, confirm your application already meets the Livewire v3 platform floor before treating the install as a drop-in. Pin the package version explicitly and record your current Livewire, Laravel, and PHP versions in your dependency manifest first.
- Does Hearth support Livewire v3, and is Livewire v2 still supported?
- The v4.1.0 release notes state that Livewire v3 support was added via issue #196. What is not clear from the release notes is whether the Composer constraint was widened to allow both v2 and v3 or bumped to v3 only, and those two outcomes have very different migration consequences. Inspect the composer.json diff between v4.0.0 and v4.1.0 to answer this definitively before planning an upgrade. There is also no documented deprecation timeline for v2 in the available evidence.
- What Laravel and PHP versions does Hearth require?
- Livewire v3 itself requires Laravel 10 or later and PHP 8.1 or later, so adopting this release transitively raises your platform floor. The exact minimums Hearth declares should be confirmed from the package composer.json rather than assumed from the changelog. If your application is still on an older Laravel or PHP baseline, plan that platform upgrade as part of the same workstream.
- Are Hearth's UI components accessible out of the box?
- The package is explicitly aimed at accessible, reusable UI foundations, which suggests inclusive markup and sensible defaults are a design goal. That said, accessibility claims should always be verified in the context of your own application rather than assumed from a package description. Test rendered components with a keyboard, a screen reader, and automated audits, paying particular attention to form labels, validation feedback, and focus handling after Livewire updates.
- Is Hearth worth using if my Laravel app doesn't use Livewire?
- Probably not. The value of Hearth's current release is entirely contingent on Livewire being your reactive layer for server-rendered components, so without an existing Livewire footprint you would be adding a dependency you would otherwise not carry. If you are evaluating Livewire independently, decide that first and treat Hearth as an optional add-on afterwards.
- How do I migrate from Livewire v2 to v3 when using Hearth?
- Treat the Hearth v4.1.0 release as an enabler for the Livewire v3 upgrade, not as the migration itself. The Livewire v2 to v3 upgrade is the larger and riskier workstream and should be planned as its own initiative with a dedicated branch and rollback plan. If Hearth's constraint turns out to be v3-only, you cannot decouple the two bumps and must upgrade them together. Exercise every UI surface that renders a Hearth component, with attention to form binding, validation feedback, and polling or deferred updates.
- How should I test Hearth components before deploying to production?
- Render every component your application uses in automated tests and assert on the resulting markup and behavior rather than just checking that the page loads. Focus on form binding, validation feedback, and any polling or deferred update behavior, since Livewire v3 changed default request and update semantics. It is also worth confirming whether Hearth's own test matrix runs against both Livewire v2 and v3, because that tells you how much confidence the maintainers have in dual support. Finally, run through the same flows manually in a staging environment before release.
- What are the main technical risks of adopting Hearth?
- The primary risk is dual-support complexity: if the package claims both Livewire v2 and v3 support from a single codebase, there is a compatibility shim inside that can accumulate conditional logic and cause environment-specific defects. A second risk is silent behavioral drift, where components written against v2 timing assumptions still work but behave differently under v3, passing CI and failing in production. A third is minor-version scope creep, which is only safe if the public API truly did not change in 4.1.0. Ecosystem lag is a smaller concern, but third-party Livewire add-ons in your stack may constrain your v3 adoption independently.
- Who maintains Hearth and is it production-ready?
- The available evidence is thin, consisting of a single feature entry from the v4.1.0 release notes, so maintainer count and release cadence should be verified directly on the repository before committing. Single-maintainer risk materially changes the operational calculus for a package that sits in your UI layer, so check the commit history, open issues, and recent releases. Until those questions are answered, treat Hearth as a reasonable fit for teams already running Livewire v3 on Laravel 10 and PHP 8.1 or later, and pilot it on a feature branch before wider adoption.
Weaver
How can I help you explore Laravel packages today?