Html Laravel Package

Product Decisions This Supports

• Roadmap triage — is this a milestone unblocker or a distraction? orchestra/html is a scoped internal accelerator for admin/back-office CRUD and extension screens. It shortens time-to-form on internal tooling, so it can legitimately unblock an internal admin milestone — but it should never appear on a customer-facing roadmap line. Decide which side of that line the work sits on before deciding whether the package matters.
• Build vs. buy vs. reuse. The honest framing: "buy" is not on the table — 0 dependents and a package score around 0.3 mean there is no vendor to buy from and no ecosystem validating the choice. The real decision is reuse vs. build. If the app already runs Orchestra Platform, the package typically arrives transitively via orchestra/foundation, making reuse near-free. If it doesn't, build — a handful of internal Blade components delivers the same convenience (model binding, CSRF, old-input repopulation) without the maintenance and escape/XSS audit burden.
• Feature scoping and surface placement. Approve it for internal admin CRUD, extension configuration screens, and HTML-heavy back-office panels. Explicitly scope it out of customer-facing, accessibility-critical, localization-critical, or revenue-critical surfaces. The Bootstrap-3-era markup and the escaping-adjacent API (Form::raw(), Html::raw()) require a security and UX audit before any external exposure — that audit is a cost line, not a footnote.
• Dependency strategy and sequencing. Make adoption a gated decision, not a default: time-boxed spike in one non-critical admin module → Composer/illuminate/* version audit → license and transitive footprint check → thin internal adapter → documented exit plan. If Composer resolution fails against your Laravel version, take the no-go. Do not fork to widen the constraint unless an existing Orchestra extension hard-depends on it.
• Delivery estimation and velocity. Where it applies, it removes real boilerplate: Form::control() collapses label + input + error markup, and Form::model() eliminates hand-written old('name', $model->name) everywhere. That is a measurable per-form saving across a CRUD-heavy admin milestone — which is the entire business case. Price the offsetting work too: control() does not reliably wire validation state, so error styling is manual, and any non-Bootstrap-3 theme needs class overrides.
• Risk budgeting — who owns this when it breaks? The v6.1.0 release only bumps orchestra/support, which is a weak maintenance signal. Treat upkeep as an owned internal cost, not a vendor-handled one. If this becomes load-bearing for an internal admin workflow, allocate owner time for upgrades, escaping/XSS verification, and eventual replacement.
• Architecture governance. Set a policy that Orchestra\Html types never appear in domain code — views call an adapter or Blade component instead. This converts a potential codebase-wide rewrite into a one-file change and keeps the exit plan credible. If someone starts extending Orchestra\Html\FormBuilder, they have coupled too far; intervene then, not at migration time.

When to Consider This Package

Consider it when:

• You are already on Orchestra Platform / Laravel. Check composer show orchestra/html first — it often arrives transitively, so adoption cost and blast radius are both near zero and confined to admin screens.
• You need speed on internal admin forms. Model binding, CSRF handling, method spoofing, old-input repopulation, and macro-based house styles for create/edit screens are the concrete payback, and you can accept thin community support in exchange.
• You have verified the fundamentals before committing: illuminate/* and Orchestra compatibility, transitive footprint, license, test coverage, release cadence, and the escaping/XSS posture of raw() helpers. Treat these as gates, not diligence theater.
• The design surface is tolerant. An internal admin theme that is Bootstrap-3-adjacent, or one where you are willing to override classes via the attributes array.

Look elsewhere when:

• The surface is customer-facing, accessibility-critical, localization-critical, or design-system-governed. A Bootstrap-3-era builder fights Tailwind, Bootstrap 5, and any component library you actually ship to users. That is a hard stop, not a trade-off.
• The codebase is Blade-components-native or Livewire-based. Introducing a second, incompatible markup convention creates a consistency problem worth more than the boilerplate it saves.
• Composer refuses the install. Take the no-go and move on; forking to force it in means inheriting maintenance the upstream team is not doing.
• You would be the first real dependent. Zero dependents means zero field reports — every edge case (duplicate _token on nested forms, model state bleeding across a missing Form::close(), facade alias collisions with Laravel Collective) is one you discover and debug yourself.
• A legacy app also installs Laravel Collective. Both alias Form and Html; whichever provider registers last wins. You can end up with a builder whose methods exist but behave differently. If you cannot guarantee registration order, skip it.

How to Pitch It (Stakeholders)

To executives — one paragraph: orchestra/html is a small internal accelerator for admin and back-office forms, not a platform bet. If we're already on Orchestra Platform it's likely installed already, so the cost of using it is close to zero and the benefit is direct: less hand-written markup per admin screen, faster internal CRUD delivery. The trade-off is that nobody else depends on it — the release history is thin — so we use it deliberately, keep it behind a thin internal wrapper, and never put it in front of customers. If we're not on Orchestra, we shouldn't adopt it; a few internal Blade components get us the same thing with no dependency.

To engineering — the operating rules:

• First, verify, don't assume. Confirm composer show orchestra/html, run php artisan package:discover, and check get_class(app('form')). If it resolves to Collective\Html\..., that's a registration bug — fix it before debugging any rendering issue.
• Standardize on Form::model() and Form::control(). Model binding is the highest-leverage feature: value population, old-input repopulation, and method spoofing for free. Any hand-written old('name', $model->name) is a signal you're fighting the builder.
• Put it behind an adapter. A small FieldFactory or Blade component layer means swapping to native Blade later is a one-file change, not a find-and-replace across the codebase. No Orchestra\Html type hints in domain code; no extending Orchestra\Html\FormBuilder.
• Respect the sharp edges. {!! !!} for anything control() returns; audit every raw() call as review-required; add has-error/is-invalid yourself since the wrapper doesn't wire validation state; watch for unclosed forms bleeding model state and duplicate _token inputs causing 419s.
• Test the rendered output, not the browser. Assert on the HTML string, and assert _token appears exactly once — duplicate CSRF silently breaks POSTs and is trivially caught by a string count.
• Pin exact versions in composer.lock with a documented upgrade procedure, and write the exit plan before the fifth form, not after.