Filament Form Builder Laravel Package

Product Decisions This Supports

• Deployment pipeline reliability (primary). php artisan optimize and view:cache are standard steps in Laravel deploy scripts and CI pre-warm. Before v5.0.1, this package could hard-fail those commands in the host application because its service provider registered and published a resources/views path the package does not ship. Any roadmap item gated on “deploys are boring and repeatable” is directly supported by adopting this patch.
• Build vs. buy. A fast, narrowly-scoped patch for a host-app integration regression is a maintenance-responsiveness signal. It argues for adopting and staying current rather than building and owning an in-house equivalent (service provider, config publishing, view/resource wiring).
• Upgrade policy / dependency governance. v5.0.1 is a patch on the v5 major line and is semver-compatible: it can be scheduled as routine maintenance, not a migration project. Supports a standing decision to track the supported v5 line with a regular composer update cadence.
• Use cases unlocked. Features that depend on view rendering and view caching at boot — admin panels, themed UI, mail templates, published view overrides — are safe to build on once the phantom resources/views registration is removed.
• Risk register / acceptance criteria. This is the classic “green locally, breaks under optimized/cached production” failure mode. It justifies adding php artisan optimize and view:cache to the PM’s definition of done and to the deploy smoke test.

When to Consider This Package

• You are on Laravel and want the capability it provides without owning the maintenance of a service provider, config publishing, and resource/view wiring.
• You run php artisan optimize, view:cache, or config/route caching in production or CI. v5.0.1 is the minimum acceptable version; do not adopt or pin below it.
• You value an actively patched v5 major line and can absorb patch releases on a routine cadence.
• Look elsewhere or defer when: you require guaranteed long-term support with no major-version churn; your app heavily overrides views and you would rather own the view namespace outright; you are on a Laravel version outside the v5 line’s support; or the underlying capability is small enough that an in-house implementation is cheaper than the integration and upgrade surface. Reconsider if your organization cannot take patch releases routinely — much of the value here is in staying current.

How to Pitch It (Stakeholders)

Executives: A patch release, v5.0.1, removes a failure mode where this dependency could break our standard production build-and-cache step. It is a low-risk upgrade with no API changes that protects deployment reliability and eliminates an outage class we would otherwise discover at release time. It also confirms the maintainer is actively servicing the package, which lowers total cost of ownership versus building and maintaining the capability ourselves.

Engineering: Upgrade to v5.0.1. No breaking changes and no application code changes expected. The fix stops the service provider from registering and publishing a resources/views directory the package does not actually ship, which previously caused php artisan optimize / view:cache to fail in host apps. Actions: bump the version constraint, run composer update, confirm php artisan optimize passes in CI, add that command to the deploy smoke test so this regression class is caught automatically, and check existing installs for a stale published resources/views directory.