Widget Laravel Package

Technical Evaluation

Architecture fit. orchid/widget is not a general-purpose Laravel library in the sense a build-vs-buy scorecard would assume. It is a split-out satellite of orchid/platform, the admin panel framework, and it inherits that framework's Widget, Layout, Field, and Screen contracts. The TPM decision is therefore binary and should be framed as a platform bet, not a package bet: adopting this means adopting Orchid's release cadence, internal rendering API, migrations, assets, middleware, and auth model.

The product value is the "cards primitive": KPI tiles, counters, activity feeds, mini-tables, and status lights with row/column placement, async loading, per-widget permission checks, and caching. That supports three concrete TPM decisions: build-vs-buy for an internal dashboard shell, deferring a BI/tooling purchase for the first two to three quarters of "we need a metrics dashboard" requests, and sequencing ops-facing features (queue health, order volume, failed jobs) once polling exists. The strongest budget argument is deferral of the procurement and data-modeling work a BI tool implies — not differentiated capability.

A note on the signal. Zero stars, zero dependents, and a 0.3 score describe the monorepo split, not fitness. This package's real adoption is Orchid's adoption. Do not enter this row into a build-vs-buy scorecard as an independent market signal; it will produce a false negative. Also flag the repository/package naming mismatch (tabuna/widget vs. orchid/widget) as a supply-chain question to confirm before any spike — canonical source and provenance are a PM's concern here, not just engineering's.

Technical risk. High, driven by project health and coupling rather than code complexity:

• Concentration risk. Single-maintainer ecosystem; assume unmaintained until proven otherwise. The realistic cost model is vendor-or-fork — i.e., an owned micro-library with a named owner and a documented exit path.
• Unstable internals. Orchid has historically shipped breaking changes across majors, and this shim has no abstraction layer to absorb them. Budget three to five engineer-days per Orchid major upgrade as a standing line item.
• Runtime coupling. Widgets often assume the admin panel's CSS/JS, middleware, and a booted Orchid kernel. Whether assets are publishable and cache-busted, and whether the render path survives config:cache and route:cache, separates a one-day spike from a three-week integration.
• Non-obvious security surface. Rendering admin widgets outside /admin can expose data implicitly protected by the admin guard; every widget must be re-audited for its new exposure context rather than inheriting the admin panel's guard.
• Marginal value against a small in-repo Blade component. The defensible reasons to take the dependency are placement, refresh, and permission plumbing you would otherwise build yourself.

Key questions.

1. Is the canonical package tabuna/widget or orchid/widget, and are they the same codebase — what is the provenance?
2. Which orchid/platform majors and Laravel/PHP versions are supported, and are constraints exact rather than floating (*, dev-master)?
3. Does it require the admin panel's routes/middleware and a booted Orchid kernel, or can it render in isolation?
4. How are widget CSS/JS assets published and cache-busted for non-admin views?
5. What is the authorization model when a widget renders outside /admin — is there a guard helper, or do we own policy checks per widget?
6. Is there a test suite, CI, tagged releases, and a license (MIT) that clearly permits forking and vendoring?
7. What is the maintainer's responsiveness, and what is our documented fork exit path?

Integration Approach

Stack fit. Viable only for a Laravel application already standardized on Orchid Platform and already living with its widget/field conventions. Everywhere else, the correct move is a small in-repo Blade component or view composer that renders exactly the markup required — roughly equivalent effort with no transitive admin-panel dependency and no third-party abandonment risk. Explicitly reject the anti-pattern of adding orchid/platform to a frontend app purely to unlock widgets.

Migration path. Two legitimate paths:

1. Orchid-native consolidation. Replace hand-rolled Blade partials and View::composer wiring with widget calls. Start with one low-risk, read-only stat tile, then expand. This is a refactor, not a re-platform, and the win is standardization — widget-based dashboards become the definition of done for back-office screens, including their authorization.
2. Reference implementation. Read the small surface, reproduce the directive and rendering contract in-repo, add tests, and own it. Given zero dependents and no observable release cadence, this is the default recommendation for any production system.

Compatibility. Pin orchid/platform explicitly and pin the widget package to a commit SHA — not a floating constraint. Validate the render path under php artisan config:cache and route:cache; service-provider-registered Blade directives survive, runtime-only registrations often do not. Confirm PHP/Laravel support against the CI matrix before the spike, and record the adoption rationale in an ADR so the next engineer does not silently inherit an orphan.

Sequencing (one to two weeks, weighted to validation).

1. Day 1–2 — spike. Branch, install, render one widget in a local Blade view. Confirm the kernel, asset, and middleware assumptions in the key-questions list.
2. Day 3–5 — hardening. Pin versions, verify cache-boot paths, add the per-widget render smoke test that will serve as the upgrade canary, and audit authorization for the target surface.
3. Week 2 — one real widget behind a feature flag. Low-risk, read-only, with caching or a precomputed aggregate and a per-widget timeout. Measure render cost under realistic data.
4. Post-flag — expand. Add tiles incrementally; each new widget is a small PR with its own test and cost review. Do not batch ten tiles into one unmeasured change.

Operational Impact

Maintenance. Treat this as internal, non-critical infrastructure: pin the parent platform, name an owner, and keep a documented fork path plus the ADR that explains why it was adopted. Budget three to five engineer-days per Orchid major upgrade and expect breaking changes across majors — there is no abstraction layer to absorb them. If the maintainer goes quiet, the assumed plan is vendor-or-fork, so verify the license and that forking is genuinely practical before committing, not after.

Support. Support is effectively self-support. There is no observable release cadence and no dependents to lean on; the community of adopters is the Orchid community. That is acceptable for a non-differentiating internal admin surface and unacceptable anywhere else. Set that expectation with stakeholders explicitly: this is time-to-first-dashboard and deferred tooling spend, not differentiated capability.

Scaling. Scaling is not a matter of user concurrency so much as query cost per tile. Widget handlers execute on every page load and refresh, so an unindexed aggregate per tile per polling interval is a real, recurring database cost. Mandate caching or precomputed aggregates and per-widget timeouts before shipping more than a handful of tiles. Async loading keeps the page responsive but shifts cost to background load; polling, not websockets, is the model — do not promise sub-second freshness.

Failure modes. Watch for: a widget whose query degrades silently as tables grow; async refresh storms when several widgets poll on the same short interval; asset/CSS breakage after a cache-bust or Orchid minor bump; render-path failures only visible under config:cache; and data exposure when a widget written for /admin is mounted on a less-protected route. The per-widget smoke test (render, assert non-empty output) is the cheap canary for the first three; a per-widget cost and authorization review covers the rest.

Ramp-up. Low for a team already fluent in Laravel/Blade and already inside Orchid's conventions — a widget is a small class with name(), description(), and render(). The ramp is not the API; it is learning Orchid's layout, fields, and auth semantics, which the team already carries if the platform is in use. For anyone else, the learning investment is the entire admin framework, which resets the calculus toward a ~few-hundred-line in-repo reproduction that the team owns and tests.

Default recommendation. If we already run Orchid, adopt the pattern and migrate one low-risk read-only widget first behind a feature flag, with caching and a smoke test in place. If we do not, reproduce the directive and rendering contract in-repo and own it — same ergonomics, no supply-chain exposure, no single-maintainer concentration, and no standing Orchid major-upgrade tax.