Aire Laravel Package

Product Decisions This Supports

• Build vs. buy for form rendering: Aire replaces hand-rolled Blade form markup with declarative, class-based form definitions (Aire\Form, sections, fields, reusable components). This is a "buy" decision for teams that keep rebuilding the same input markup, error display, and old-input repopulation logic on every CRUD screen.
• Feature velocity on internal/admin tooling: The main payoff is in back-office and CRUD-heavy surfaces, where a form can be defined in a small PHP class instead of hundreds of lines of Blade. Useful for roadmapping admin panel work, ops tooling, and multi-step wizard flows.
• Consistency and design-system leverage: Centralizing field rendering makes it cheaper to enforce a design system, accessibility attributes, and error states — a lever for design consistency and a smaller QA surface on forms.
• Platform upgrade planning: 2.16.0 adding Laravel 13 support directly informs the framework upgrade timeline. This package is no longer a blocker for an L13 migration, so it can stay on the roadmapped upgrade path.
• Dependency risk budgeting: A small, opinionated, single-maintainer-style package is a deliberate trade (low ceremony, low control). This feeds into the dependency register and the "what breaks if this goes unmaintained" contingency plan.

When to Consider This Package

Adopt when:

• You are on Laravel (this release extends support through Laravel 13) and your forms are server-rendered Blade, not a SPA/JSON form stack.
• Forms are a meaningful share of your surface area — admin panels, settings screens, onboarding, CRUD — and markup duplication is a real cost.
• Your team is comfortable with PHP-defined UI (classes over templates) and Tailwind-ish styling conventions out of the box.
• You want validated, repopulated, error-aware forms without adopting a full admin framework.
• You can accept a thin dependency and are willing to pin/vet versions at upgrade time.

Look elsewhere when:

• Your front end is Inertia/React/Vue/Livewire-driven and form state lives client-side; Aire's value proposition shrinks considerably.
• You already use a batteries-included admin stack (Filament, Nova) whose form layer would be duplicated or fought.
• You need guaranteed long-term vendor support, SLAs, or a formal deprecation policy — this is community OSS.
• You are stuck on an older Laravel version outside the supported range, or you maintain a strict "no small-dependency" policy.
• You need highly dynamic, conditional, or schema-driven forms where the definition must come from runtime config rather than code.

How to Pitch It (Stakeholders)

For executives (30 seconds): We use Aire, a small open-source Laravel package that lets engineers define forms in code instead of hand-writing HTML for every screen. It cuts repetitive work on our admin and settings pages, enforces a consistent look and error handling, and reduces bug surface in forms. This release confirms it works with the newest Laravel version, so it's not an obstacle to our upcoming framework upgrade. Risk is low and contained: it's a rendering layer, not a data or infrastructure dependency, and forms can be reverted to plain Blade if needed.

For engineering: 2.16.0 is a compatibility-only release adding Laravel 13 support — no API changes, no migrations, no deprecations. Treat it as a routine minor bump: update the constraint, run the form-related test suite, and confirm styled output and validation error rendering are unchanged. The package remains appropriate for Blade-rendered forms; if we move a surface to Inertia/Livewire, that surface should not adopt Aire. Keep it pinned, review it at each Laravel major, and avoid spreading it into areas where a client-side form stack is planned.