Filament Single Record Resource Laravel Package

Technical Evaluation

Architecture fit. The package is correctly scoped for its problem: two composable traits (HasSingleRecordResource on the Resource, HasSingleRecord on ViewRecord/EditRecord) plus an optional SingleRecordResolvableResource contract. It does not monkey-patch Filament internals — it hooks the documented authorization, navigation, page-resolution, and breadcrumb extension points. That keeps coupling to the framework at a level Filament itself expects plugins to use, which is the main thing a TPM should care about: the blast radius of an upgrade is bounded to two traits and one interface.

Integration feasibility. Installation is composer require coringawc/filament-single-record-resource and adding a trait to a Resource and its view/edit pages. There is no config file, no migrations, no service provider wiring required by the consumer, and no published assets. For a team already on Filament, the integration cost is measured in hours for a first resource, not weeks. The README's "Step-by-Step" section is directly actionable.

Technical risk. The risk profile is dominated by project health, not runtime safety:

• Bus factor 1. Single maintainer (CoringaWc), 12 stars, 0 dependents. The package is one person's weekend problem-solver that has been packaged cleanly. That's fine for use, unacceptable for dependency without a fork plan.
• Version churn. Filament 4 → 5 support is already in the constraint set (^4.0 || ^5.0), but the package is at v1.1.2 with only 5 months of releases. Expect trait behavior to shift with Filament minors.
• Authorization semantics. The critical behavior — "allow access when viewAny is denied but view is allowed on the resolved record" — is a real footgun. It is the right design for a single-record resource (there's no collection to list), but it inverts Filament's default authorization path. A regression here is a data-exposure bug, not a cosmetic one. The v1.0.4 fix suggests this area has already needed correction.
• Nested chains. The deep-nesting story ("MyWallet → Companies → Products") explicitly recommends enforcing strict query scoping in models/pages when parent IDs are removed from URLs. That is correct advice, but the package does not enforce it — the consumer owns the leak-prevention.

Key questions for the team before adoption:

1. Do we have any "one-record-per-user" surfaces in the current backlog? If not, this package has no buyer.
2. Is our Filament policy model prepared to express and test the viewAny-denied / view-allowed case per resource?
3. Do we intend to publish nested child resources under a single-record root, and if so, are our models already scoped by an ownership chain?
4. Will we accept the maintenance burden of vendoring/patching, or do we require an active upstream with >1 maintainer?
5. Does the team's Filament version (4 vs 5) match what CI here validates (both)?

Integration Approach

Stack fit. Native to Filament ^4.0 || ^5.0 with whatever Laravel major the chosen Filament ships against (11/12 at time of writing). No PHP extension or service dependency. Composer-only install; nothing to deploy.

Migration path. Treat this as additive, greenfield-only. Do not retrofit existing index-based resources — converting UserResource (list of all users) into a single-record resource is a semantic change, not a refactor. The correct usage is to identify a page that should never show a collection (Profile, Wallet, Settings, Current Subscription) and build it fresh with HasSingleRecordResource + HasSingleRecord. Existing resources keep their index pages and their viewAny semantics.

Compatibility notes.

• Pin to a minor (^1.1) rather than floating; the project is too young for * or dev-main.
• Implement SingleRecordResolvableResource on every Resource adopting the trait — this is explicitly the static-analysis-friendly path and prevents future divergence between legacy and contract-based behavior.
• Verify belongsTo(User::class) on the model matches the auth guard used by the panel; if multi-panel or multi-tenant, use resolveSingleRecord() on the Resource rather than relying on the default builder.
• If tenant scoping is in play, override resolveSingleRecordBuilder() on the Resource so authorization fallback and page loading resolve against the same query.

Sequencing.

1. Pilot (1 sprint): one low-risk resource (e.g. "My Profile"), policy with viewAny denied and view allowed, Pest test asserting both authorized and unauthorized paths.
2. Validate nesting (1 sprint): add a child resource under the pilot to confirm root URL/slug + breadcrumb behavior; add a test that a user cannot reach another user's child record when parent IDs are absent from the URL.
3. Standardize (0.5 sprint): document the pattern in an internal AGENTS.md so every future "My X" page follows the same shape; decide once whether to vendor or depend.
4. Expand: only after the pilot and nesting case are green.

Operational Impact

Maintenance. Low code surface (two traits, one interface) means low internal maintenance — but the upstream maintenance model is a single maintainer, single-contributor repo. As a TPM I would treat this as: depend on it, but own a vendored copy if the "My X" pattern becomes load-bearing in the product. MIT license makes vendoring trivial and legally clean. Budget ~1–2 hours per Filament major upgrade to re-verify the trait contracts against ViewRecord/EditRecord.

Support. Community-only: GitHub issues and a CHANGELOG. No SLA, no paid support, no LTS branch. Acceptable for a UI convenience layer; not acceptable for anything security-critical without internal test coverage backing it.

Scaling. Runtime cost is negligible — one scoped query per page load (whereBelongsTo(auth()->user()) by default). There is no caching layer, no queue, no background work, no extra table. Nested chains compound queries in the normal Filament/Livewire way; the package does not add N+1 risk beyond what the consumer's relations already carry. This is not a scaling concern.

Failure modes to plan for.

• Authorization regression. The viewAny-denied → view-allowed fallback is the highest-risk behavior. Any upstream change here can silently widen access. Mitigation: pin the version, add a feature test per resource that asserts an unauthorized user gets 403/redirect on both view and edit.
• Null resolution. When a user has no Wallet/Profile yet, the default builder returns null. The README's resolveSingleRecord() example uses firstOrCreate([]) — decide explicitly per resource whether "no record" means create-on-visit, empty state, or 404, and encode it in the Resource method rather than relying on the default.
• Nested URL scoping. When parent IDs are removed from URLs, the package's own docs warn that the consumer must enforce strict query scoping. This is a consumer-owned failure mode. Mitigation: authorize and constrain children against the resolved root record, not just against a route parameter — and test it.
• Filament major upgrade. A v4 → v5 jump requires re-running the pilot test suite. The repo's CI validates both majors, which is reassuring but only at the package author's own test cases, not ours.

Ramp-up. Very low. A developer already fluent in Filament learns this in under an hour by reading the README's three-step example; the concepts (view/edit-only pages, resource-level resolution hooks, contract interface) are Filament-native, not package-invented. The main onboarding cost is not the package — it is teaching the team the authorization fallback and the nested-scoping rules, because those are the areas where misuse is possible and the package deliberately leaves the guardrails to you.