Delia Laravel Package

Technical Evaluation

Architecture fit. Delia is a Filament panel plugin, not a general-purpose Laravel library, and it should be evaluated as a plugin in the admin-panel layer rather than as application infrastructure. Its footprint is small and well-bounded: a per-user persistence table, a toggle affordance surfaced through Filament's render hooks, and a filtered navigation view. That shape fits cleanly into a standard Filament panel provider registration and does not require changes to domain models, routing, or the request lifecycle. The architectural risk is therefore not "will this contaminate our app" — it won't — but "does the feature belong in our admin panel at all." At 7 stars and 0 dependents, Delia is a narrow UX feature with a thin dependency surface; treat it as a bounded experiment inside a panel, not as a platform building block.

Integration feasibility. Feasible in an afternoon for a team already on Filament: composer require, publish config and migrations, migrate, register the plugin in the panel provider, republish assets, clear caches. The dominant uncertainty is version pairing, not effort. Delia 3.0.0 exists solely to support Filament 5, which means the package is coupled to your platform major and the install is really a resolution exercise. A dry-run install tells you the real PHP/Laravel/Livewire floors and whether filament/filament is constrained to ^5.0 only. Everything downstream depends on that answer.

Technical risk. Three risks matter to a TPM, in order:

1. Vendor sustainability. Single maintainer, near-zero adoption, MIT, and a release note that says only "support filament 5." Mitigation is structural: the surface area is small enough that forking or reimplementing (a pivot table plus a nav render hook, roughly one to two days of engineering) is a credible fallback. That fallback must be named and owned before adoption, not discovered during an incident.
2. Documentation credibility. The repository description and the supplied package summary describe structured dynamic menus with Blade rendering helpers; the actual package is a bookmark manager for Filament resources. Those are different products. When vendor documentation does not describe the thing being installed, the true evaluation cost shifts onto source review — an hour of reading src/*Plugin.php, the migrations, and the config, budgeted explicitly. If that hour is not available, the package is not ready to evaluate.
3. Correctness gaps that are ours to close. Authorization (can a user bookmark a resource they can no longer access; does the bookmark list respect canAccess()), tenancy (does the schema carry a tenant discriminator, or do bookmarks leak across tenants for multi-tenant users), cascade behavior on user and resource deletion, and N+1 query patterns on large nav trees. None of these are documented; all are verifiable in staging in under an hour each.

Key questions.

• Is Filament 5 already on the roadmap, or is this package the reason to consider it? If the latter, stop — Delia is a rider on that upgrade, not a driver.
• How many resources does the target panel expose? Under a dozen, this is a solution without a problem.
• Does the migration include a tenant or panel discriminator? If not, is the target panel single-tenant?
• Do we accept single-maintainer, zero-adopter dependencies on internal panels, and who is the named internal owner if we do?
• What is our internal build cost for a pivot table plus a nav filter, priced honestly against adoption plus tracking plus upgrades?
• Are the users internal only? Any customer-facing surface is out of scope for a package with these adoption signals.

Integration Approach

Stack fit. Requires a Filament panel (v5 for Delia 3.x, v3/v4 for 2.x), Laravel and Livewire at the floors declared in composer.json, and standard asset publication for panel CSS/JS. Delia slots in beside existing panel plugins without competing for the same extension points. It does not replace Filament's native navigation — the intended composition is Delia as a pinned/frequently-used surface layered on top of the existing nav tree, so muscle memory is preserved and removal is non-destructive.

Migration path. Two distinct paths, and they should not be conflated:

• Filament 4 → 5 upgrade in flight: bump Filament, bump Delia to ^3.0, republish assets, run migrations, smoke-test navigation and the bookmark toggle — ideally in the same branch and the same PR. Write the rollback (revert lockfile, roll back migration, clear caches) before starting.
• Standalone trial on an existing panel: stay on the Delia line that matches your Filament major (2.x for v3/v4, 3.x for v5). Do not attempt to adopt 3.x ahead of a Filament 5 migration; resolution will fail or force an unplanned platform bump.

In both cases the persistence migration is real (bookmarks are user-generated rows), so treat the schema change as a production change: review the migration file, confirm the foreign key behaves as you expect, and decide the table name before it ships — bookmarks collides easily with an existing app table, and renaming after data exists is avoidable work.

Compatibility. Pin the minor (^3.0.x equivalent), commit the lockfile, and treat Filament patch bumps as events that require re-running the plugin's smoke test — a thin plugin can break on patch-level changes without any signal from the vendor. Model overrides are supported through config, but if you override the model, keep the package's contract intact or the plugin's own Livewire components break at runtime in ways that are tedious to trace. If you fork or override the migration, record the fork decision in an ADR at that moment, because that is the line where "we use Delia" becomes "we maintain Delia."

Sequencing.

1. Dry-run install to establish the resolution facts; stop here if there is a conflict.
2. Source review: plugin class and make() signature, migration schema (tenant column?), config knobs.
3. Register behind a config flag in a single resource-dense internal panel; off in production.
4. Staging pilot with two or three seeded accounts holding different bookmark sets; verify persistence across logout/login, empty state, ordering, and authorization filtering.
5. Query-count the largest panel against baseline before enabling broadly.
6. Production rollout to internal panels only, gated per panel and per environment via config('features.delia') so removal is a one-line change.
7. Add one Livewire assertion to CI that toggles a bookmark and asserts the row exists — this converts silent breakage into a red build.

Operational Impact

Maintenance. Low in absolute effort, non-zero in attention. The package is small and MIT, so the work is not patching but watching: version pairing with Filament majors, republishing assets after panel upgrades, and re-diffing any published Blade views you have edited (they fall out of sync silently). Assign a named internal owner. Without one, this dependency will be discovered only when a Filament bump breaks bookmarks and nobody knows when it stopped working.

Support. Vendor support is effectively absent at these adoption levels; the realistic support model is internal triage plus fork-or-reimplement as the escalation path. Plan the budget accordingly: adoption is cheap, but the decision to adopt includes accepting that the second line of support is your own team. Keep the feature flag so the fastest remediation is always "turn it off," not "debug it now."

Scaling. Two dimensions:

• Users and rows: trivial. Per-user bookmark rows are small and grow with engagement, not with data volume. Confirm cascade deletes so departed users don't leave orphan rows that quietly skew counts.
• Query pattern: the real scaling concern. If bookmark state resolves per-resource per-request, a large navigation tree becomes an N+1 on every admin page load. Measure with query logging in the pilot on the biggest panel. This is a per-request cost paid on every admin page, so it compounds across the user base in a way row count never will.

Multi-panel estates need a decision rather than a default: register Delia on internal panels only, and explicitly not on customer-facing ones.

Failure modes.

Ramp-up. Minimal per developer — the integration is a plugin registration, a config publish, and a migration, all familiar Filament mechanics. The non-obvious cost is the evaluation pass: roughly an hour of source and schema reading to establish version floors, tenancy behavior, and the plugin contract, plus a short pilot. Budget that explicitly and it is a day of work end to end for one engineer. Skip it and the cost reappears as production ambiguity around authorization and tenancy, which is the expensive place to learn.

The product framing to carry into the decision: this is a cheap UX experiment on internal surfaces, riding the Filament 5 upgrade, with a credible one-to-two-day internal build as the alternative. Adopt only where navigation friction is a voiced complaint and a fork owner can be named; otherwise close it out and spend the day on the thing users actually asked for.