Aire Bootstrap Laravel Package

Technical Evaluation

Position in the stack. glhd/aire-bootstrap is a presentation-layer package: it ships Blade views and components that render Bootstrap-form markup for fields, labels, help text, validation feedback, and buttons generated by the Aire form builder (glhd/aire). It carries no business logic, no persistence layer, no queue or HTTP surface, and almost certainly no migrations. Its only job is to convert Aire's PHP form API into HTML that matches a Bootstrap design system.

Architecture fit. Good, and deliberately narrow. For a Laravel monolith or admin panel already standardised on Bootstrap and building server-rendered forms, this removes a class of recurring duplication — every team that hand-rolls form partials eventually drifts on label markup, is-invalid class placement, and aria-describedby wiring for error text. A theme package centralises that. The coupling is one-directional (theme → Aire), which means the theme is swappable if Aire's theme contract is stable, and Aire is swappable if we accept re-doing markup. That is an acceptable dependency shape for a UI concern.

Integration feasibility. Mechanically trivial: a Composer require, service-provider auto-discovery, and a vendor:publish for the views. The realistic effort is not installation but verification — confirming the published Blade views render correctly against our Bootstrap version, our validation error bag conventions, and any custom Aire field types we use.

Technical risk. The dominant risk is not technical, it is adoption and lifecycle:

• Effectively unvalidated in the wild. Six stars and zero dependents means we would be among the first non-author consumers. There is no community signal that these views behave correctly across Bootstrap minor versions, Laravel validation edge cases (nested arrays, old() repopulation, file inputs), or accessibility audits. We are the QA function.
• Staleness. Last release is April 2023, pinned to Laravel 10 support. Laravel 11 and 12 are not evidenced. As a view-only package it may work unmodified, but "works" and "supported" are different claims for a dependency we intend to keep through framework upgrades.
• Transitive coupling to Aire. The theme cannot outlive or out-version Aire. If glhd/aire goes quiet, this package is stranded regardless of its own health. The maintenance question must be asked of Aire, not of this repo.
• Bootstrap version ambiguity. Whether these views target Bootstrap 4 or 5 materially changes markup (form-group/custom-select vs mb-3/form-select, invalid-feedback placement). Getting this wrong produces forms that look plausible but fail accessibility and layout review.
• Low blast radius. Mitigating all of the above: broken output is wrong HTML, not corrupt data or a security hole. Blade escapes by default. Failure is visible in a browser and reversible by publishing and editing views. This is the safest category of third-party dependency to trial.

Key questions (blocking before approval).

1. Which Bootstrap major is targeted, and does it match our design system today?
2. Which Aire major is required, and is Aire itself maintained for Laravel 11/12? What is Aire's release cadence and issue-close rate over the last 12 months?
3. Does the package ship anything beyond views — config, migrations, service provider bindings, asset pipeline hooks?
4. Are the views fully publishable and override-friendly, or do custom field types require touching vendor code?
5. Is there any CI matrix (Laravel × PHP versions) we can inspect, or is "Laravel 10 support" a constraint bump only?
6. Who maintains Glhd packages, and what is the bus factor? Can we fork under MIT if needed?

Integration Approach

Stack fit. Laravel 10 / PHP 8.1+, Composer 2, Bootstrap-based front end, Aire as the form builder. If we are not already on Aire, this package is not a starting point — it is a theming decision made after the form-builder decision. Adopting it as a way to "get Bootstrap forms" inverts the dependency.

Migration path.

1. Confirm Aire first. Install and validate glhd/aire on a single non-critical form. If Aire does not resolve cleanly on our Laravel version, stop — the theme is moot.
2. Add the theme in isolation on a branch, publish views to resources/views/vendor/aire-bootstrap, and diff the rendered output against one existing hand-written Bootstrap form. This single exercise answers the Bootstrap-version question and the validation-markup question simultaneously.
3. Rewrite forms incrementally, screen by screen. Aire forms are declared in PHP, so migration is per-form, not per-application. Keep the hand-written partials until each screen has passed visual and accessibility review, then delete.
4. Lock in the override pattern early. Any deviation from the shipped markup goes into published views or a thin wrapper component — never into vendor/. If overrides exceed roughly a dozen views, reassess whether the package is earning its place versus a small in-house partial set.
5. Pin deliberately. Use ^2.1.2 and commit the lockfile. Given the release gap, avoid dev-main; an unreleased branch is not a supportable baseline.

Compatibility checks. PHP 8.1 floor; Bootstrap major version match; interaction with our validation error-bag naming (Aire typically reads Laravel's $errors, but confirm translation/attribute-name customisation); any CSP or asset-build implications if the views pull in Bootstrap JS for tooltips/popovers; and a pass with E_ALL to catch deprecations if we trial it on Laravel 11+.

Sequencing. Theme spike (1–2 days on one screen) → design/accessibility sign-off on markup → roll into the form backlog as normal feature work → framework upgrade is handled independently. This deliberately decouples the theme decision from the Laravel upgrade, because the theme is not load-bearing for the upgrade.

Operational Impact

Maintenance. Low and predictable, with a caveat. View packages do not degrade on their own; they degrade when Bootstrap or Laravel moves. Budget one review per Bootstrap major and one per Laravel major — a few hours each, not a standing allocation. The real ownership cost is the published views: once forked into resources/views/vendor, they are our code and will not receive upstream fixes. That is the correct trade (customisation beats upgrade convenience for markup), but it must be a conscious decision recorded in the repo.

Support. Community-only, no SLA, small maintainer surface, and near-zero downstream users to corroborate issues. Escalation is an upstream issue, then a fork. MIT licensing and a Blade-only surface make the fork path genuinely cheap — this is the package's strongest operational property and should be stated explicitly in the approval.

Scaling. No runtime scaling concern: rendering cost is Blade compilation, identical to hand-written partials, and the package adds no queries, no caching layer, and no per-request service work beyond Aire's own. The organisational scaling question is design-system drift — a shared theme is better than N teams hand-rolling Bootstrap forms, so this package improves consistency as headcount grows, provided the published views are treated as a governed shared asset rather than per-team copies.

Failure modes.

• Silent markup regression after a Bootstrap upgrade. Forms render, but classes are wrong — misaligned invalid-feedback, missing aria-invalid. Caught by visual review and an accessibility check, not by tests. Mitigate with a small set of snapshot tests on rendered form HTML for two or three representative forms.
• Framework-upgrade blocker. If Aire stalls on Laravel 11/12, the blocker sits upstream of this theme. Mitigate by keeping form definitions in application code (they already are) so the theme is replaceable without touching form logic.
• Abandonment. Likely over a multi-year horizon given the 2023 release date. Mitigated by forking; the fork cost is measured in days.
• Override sprawl. If we publish and diverge heavily, we inherit maintenance without upstream benefit. Mitigate by reviewing overrides quarterly.

Ramp-up. Half a day for a Laravel-fluent engineer to read the views, publish them, and render one form. One to two days including the first real screen and an accessibility pass. The TPM-side ramp-up is smaller still: the decision hinges on two facts (Bootstrap version, Aire health) that are answerable in an afternoon.

Leverage summary for a TPM. This package's value is consistency at near-zero coordination cost: it lets multiple squads produce Bootstrap-consistent, accessible forms without a design-system ticket per screen. Its cost is a small, well-bounded dependency on a low-adoption upstream. Recommendation: approve as a trial on non-critical screens, contingent on answers to the Bootstrap-version and Aire-maintenance questions, with published views treated as owned code and a pre-agreed fork plan. Do not adopt it as a reason to choose Aire, and do not let it gate a Laravel upgrade — the migration path above keeps those decisions independent.