Laravel Custom Fields Laravel Package

Technical Evaluation

Architecture fit. The package addresses a real and recurring need: letting administrators or tenants define fields on Eloquent models without shipping a migration for every change. The Filament integration signals the intended consumer is an internal admin panel or back-office tool, not a public API surface. Fit is therefore conditional on where the schema extension lives — if custom fields are confined to admin CRUD and reporting, the pattern is appropriate; if they are expected to participate in domain queries, indexing, or API contracts, the storage model becomes the deciding factor. The description does not disclose whether fields are stored as a JSON column, a normalized EAV table, or a side table, and that single choice drives query characteristics, validation, and migration behavior.

Integration feasibility. Mechanically straightforward for a Laravel shop: Composer install, likely a service provider with auto-discovery, published config and migrations, a trait applied to target models, and Filament form/table components for field definition and rendering. The real gating items are the version compatibility matrix (Laravel major, PHP floor, Filament v3 vs. v4 — these are materially different APIs and a common breaking point) and whether the migration set is additive and reversible. Because dependents are zero, there is no corpus of real-world installs to infer compatibility from; it must be verified empirically.

Technical risk. High, and driven primarily by validation signals rather than code quality: zero stars, zero dependents, and a score of zero mean no external production evidence, no issue history to gauge responsiveness, and no community security review. The maintainer appears to be a single agency (Skylence), so bus factor and long-term support are unresolved. Dynamic field systems are also structurally risky — they move schema decisions from developers to users, which means data integrity, validation, and orphaned-data handling become runtime concerns. Filament coupling adds a second upgrade cadence you do not control.

Key questions.

• What is the storage strategy (JSON, EAV, side table), and how are custom fields queried, filtered, and sorted — especially in Filament list views where N+1 and full-table scans surface first?
• What field types and validation rules are supported, and can validation be enforced server-side independently of the Filament form?
• What happens to stored data when a field definition is deleted or its type changes? Is there a migration/backfill path?
• Is multi-tenancy or per-model field scoping supported, and how are field definitions authorized?
• What are the exact Composer constraints (PHP, Laravel, Filament), and is there a CI pipeline, test suite, and static analysis baseline?
• What is the license, and is there any commit history, tagged release, or changelog indicating active maintenance?
• Is there a documented upgrade path across Filament majors?

Integration Approach

Stack fit. Presumed fit is Laravel 10/11/12 with Filament 3 or 4 and PHP 8.1+. Confirm before anything else; a mismatch on Filament major alone can invalidate the evaluation.

Migration path. For a greenfield admin tool, integration is low-friction: install, publish, run migrations, attach the trait, define field sets in Filament. For an existing system, the hard part is reconciling with whatever already exists — bespoke JSON columns, an in-house EAV table, or hardcoded nullable columns. Map existing custom-field data to the package's storage shape early; a lossy mapping is a reason to stop.

Compatibility. Pin exact versions in composer.json, run the package against the same Laravel/Filament versions as production in an isolated app, and treat the package's own constraint file as authoritative over the README. Check that published migrations do not collide with existing table names.

Sequencing.

1. Source audit: read the migrations, trait, and Filament components; confirm test coverage, license, and last-commit date.
2. Sandbox spike in a throwaway Laravel + Filament app at production versions; exercise create/read/update/delete of field definitions and the resulting data.
3. Benchmark the list-view path with a realistic row count to expose query behavior.
4. Compare against alternatives — Spatie schemaless attributes, a hand-rolled JSON column plus Filament's form builder, or a maintained Filament custom-fields plugin — on the same spike.
5. Decide build vs. buy vs. fork. Given the signal profile, forking and owning the code is the realistic outcome if adopted.
6. If adopted, wrap access behind a small internal interface so the package can be swapped without touching domain code.

Operational Impact

Maintenance. Assume you will own it. With no dependents and no visible community, upstream fixes and Filament-major upgrades are unlikely to arrive on your schedule. Budget for a fork with your own tests and a pinned Filament compatibility branch; treat upstream as a source of patches, not a support channel.

Support. No SLA, no published security policy, unknown issue-response time. For an internal admin tool this may be tolerable; for anything customer-facing or compliance-adjacent it is not.

Scaling. The failure mode is query cost, not storage volume. JSON columns cannot be indexed the way real columns can, and EAV requires joins per field. Filament tables that render and sort on custom fields will degrade as row counts and field counts grow. Plan for pagination, selective field loading, and possibly a denormalized read model if reporting depends on custom fields.

Failure modes. Schema drift between field definitions and stored payloads; orphaned data after field deletion; validation bypassed via direct model writes outside Filament; a Filament minor upgrade breaking the admin UI; migration conflicts on shared databases; silent type coercion when a field's type is changed. Each warrants a guardrail — server-side validation, soft-deletion of field definitions, and a data-retention policy.

Ramp-up. Low conceptual ramp-up for anyone fluent in Laravel and Filament; higher than expected for internals, because documentation is likely thin and the source becomes the reference. Allocate a few days for the spike and a comparable amount for the audit; do not schedule adoption on the assumption that the README is complete.