Widget Laravel Package

Product Decisions This Supports

• Pluggable dashboards vs. hard-coded panels. The core fork this forces: should the admin or customer home screen expose named widget areas that modules register into, or should one team own every panel? Even if we never install the package, it frames the question concretely — registration by name, placement into a region, ordered resolution, permission gating, render.
• Build vs. buy for a widget registry. Treat this as a reference implementation of the pattern, not a candidate dependency. It answers "what is the minimal viable widget contract?" — id, area, order, visibility predicate, render callable, cache TTL — which is the artifact we actually need to agree on.
• Extension-ecosystem timing. A widget area is precisely the seam where internal package authors or third parties inject UI into a host app. The decision is whether to formalize that plugin API now or defer until at least three real contributors exist.
• Roadmap sequencing. A widget layer is a platform feature: it only pays off once multiple modules want to contribute UI. With fewer than ~3 such contributors in the next two quarters, building it is premature regardless of package choice.
• Cheap reference architecture. The area/registration/resolution split is roughly a one-day pattern to copy into a first-party service provider plus Blade components, yielding a defensible contract we own outright.
• Out of scope. It does not inform generic front-end component systems, Livewire/Inertia component libraries, or dashboard-framework selection (Filament, Nova). Evaluate those as a separate category with their own criteria.

Recommendation: keep as an internal reference architecture, not a dependency. No vendor, no support contract, effectively no user base (zero dependents, zero stars, 0.3 score). Adopting means owning every line forever; copying the shape costs a day or two once the roadmap actually calls for a plugin surface.

When to Consider This Package

Consider it when:

• You already run Orchestra Platform and need its native widget component — the coupling to Orchestra's container, extension manager, memory config, and ACL is the point, not an obstacle.
• You want to read the source as a design reference for a registry pattern; it is compact and legible, and the pattern transfers cleanly.
• You have a frozen, internal-only Laravel app where a small vendored or adapted widget layer is acceptable and you fully control the upgrade path.
• Your team already knows Orchestra's idioms and won't pay a learning tax on extensions, memory, and platform bootstrapping.

Look elsewhere when:

• You are on stock Laravel — the package assumes Orchestra's service provider, extension, and configuration conventions. Wiring it standalone implies pulling orchestra/support and related contracts; that is more work than writing ~150 lines of our own registry.
• You need maintenance guarantees. Zero stars, zero dependents, and a 0.3 score are honest signals: no downstream bug reports, no community patch stream, no answer ecosystem. Plan to own every bug and every upgrade.
• You need documentation, support, or a hiring pool — none exist at meaningful scale; onboarding cost is entirely internal.
• You need a ready-made dashboard product. Filament, Nova, or a Livewire dashboard ships UI, permissions, and persistence out of the box; this is plumbing only.
• You require modern framework versions. The latest documented release (v6.0.0) targets Laravel 8 — a hard ceiling signal that is out of support on most current roadmaps. Verify php and illuminate/* constraints before spending evaluation time.

Cheap go/no-go gate (~half a day): confirm PHP/Laravel constraint compatibility, confirm the package boots without Orchestra's full stack, confirm the widget contract is stable across majors, confirm license and last-commit date. Any failure ends the evaluation. Benchmark mature alternatives (arrilot/laravel-widgets, Filament widgets, Nova cards) first if we want something off the shelf.

How to Pitch It (Stakeholders)

To executives: This is not a purchase decision — it's a pattern decision. There is no vendor, no support contract, and effectively no user base, so "adopting" it means owning it forever with no one upstream to fix anything. Its value is that it demonstrates a small, proven shape for "modules contribute UI blocks to a host screen," which we can reimplement in one to two engineering days when the roadmap actually calls for a plugin surface. Recommendation: keep it as an internal reference, do not add it as a dependency, and revisit only if we commit to a multi-module admin platform. The failure mode isn't a security incident — it's a silent internal fork we maintain indefinitely because nobody else uses it; the Laravel-upgrade tax then lands entirely on us, and that annual maintenance line is real.

To engineering: It's a compact widget registry — named areas, ordered registration, permission-aware resolution, namespaced view rendering — built for Orchestra Platform and therefore entangled with that ecosystem's container, extension manager, and ACL. Read it, don't install it. If we build our own, copy the area/registry/resolver separation, keep the widget contract minimal (id, area, order, visibility predicate, render callable, cache TTL), and put it behind a feature flag before wiring any real dashboards. Budget one to two days for a first-party equivalent with tests, versus an open-ended compatibility and ownership burden from vendoring. Known watch-items: removed Laravel helpers (array_get, str_*), Composer constraint deadlock during Laravel upgrades, and the signature bug of "renders empty string" — almost always registration order or an undeclared area, not the render method. Add CI that every registered widget resolves and renders.

Risk framing: Low cost to evaluate, high cost to depend on. Maintenance status is unverified, documentation is sparse and dated, and the realistic support model is "one or two people who have read the source" — a bus-factor worth naming. Reimplementing keeps the surface inside the platform team's normal ownership and upgrade cadence, which is the whole argument for reimplementation.