Custom Fields Laravel Package

Technical Evaluation

Architecture fit. The package implements an EAV-style extension layer: custom field definitions live in package-owned tables, and values are stored out-of-band against your Eloquent model rather than as columns on your table. Integration is deliberately thin — one trait (UsesCustomFields), one contract (HasCustomFields), one panel plugin (CustomFieldsPlugin::make()), and a fluent builder call (CustomFields::form()->build()) inside each Filament schema. That is a good fit only if your admin surface is Filament. If custom field data needs to surface in a customer-facing Inertia/Livewire/API path, you are writing that read layer yourself; the package's value proposition is form/table/infolist rendering, not a query API.

Integration feasibility. Low-effort for the happy path: no migrations on your own tables (the headline claim), no changes to existing columns, additive trait. The real effort is not wiring, it is governance — deciding who owns field definitions, whether they are runtime data or reviewed configuration, and how they propagate across environments.

Technical risk. Ranked:

1. License. AGPL-3.0 with a commercial option for closed-source. This is a go/no-go gate that legal must clear before engineering time is spent. Confirm whether "internal-only admin" is treated as distribution under your counsel's reading, and get commercial pricing and terms in writing.
2. Upgrade coupling. The package forces majors in lockstep with Filament: v2.0.0 required Filament 4, v3.0.0 required Filament 5 and Laravel 12. Your Filament upgrade calendar and this package's release calendar become the same dependency chain. A lag on their side blocks your security patching.
3. Bus factor. Changelog attribution indicates effectively a single maintainer. 168 stars and zero listed dependents means a thin community — edge cases are yours to solve.
4. Storage envelope instability. v3.0.0 changed phone storage to structured JSON and email to JSON arrays, requiring a dedicated upgrade command. Evidence that per-type value formats are not a stable contract across majors. Plan for data-shape migrations at every package major.
5. SemVer discipline on UX defaults. v3.8.0 changed select search-box rendering behavior in a minor release (self-described as "a taste change, not a bug fix"). Configurable and opt-out, but a signal to read every changelog before bumping.

Key questions. Which tenancy model does it assume (Filament panel tenancy vs. an external package), and how is isolation enforced — by scope, by column, or by convention? Can custom field values be filtered/sorted/aggregated in SQL without going through Filament? What is the published SLA for a Filament-major-compatible release? How are encrypted fields keyed and rotated? What happens to stored values when a definition is deleted versus deactivated? Is there a supported export of definitions and values, or is exiting the package a manual data extraction?

Integration Approach

Stack fit. Hard requirements are PHP 8.3+, Filament 5.0+, Laravel 12 (Laravel 13 supported as of 3.1.6). If you are on Filament 3 or 4, you are limited to older package majors that are no longer receiving features — pin your Filament major first, then select the package major that matches. Do not adopt this package on a Filament version you intend to leave.

Migration path. composer require, publish config/custom-fields.php, run the package migrations, add the trait and interface to each target model, register the plugin per panel, then insert builder calls into each resource's form, table, and infolist. If upgrading an existing install across v3, run vendor/bin/custom-fields-upgrade for the phone/email format reshape.

Compatibility checks worth doing before the spike. Database driver — the 3.1.1 patch for "MariaDB driver" and the $guarded model fix indicate portability rough edges; the maintainer's performance measurements are Postgres-based. Also verify behavior on models with $guarded = [] and on any model already using heavy attribute casting or accessors.

Sequencing.

1. Legal/license decision (blocking).
2. Pin Filament major; confirm PHP and DB matrix.
3. Two-day spike: one low-risk resource, 2–3 field types, one table column, one infolist entry.
4. Decide the definitions operating model — admin-authored at runtime vs. seeded and version-controlled. This decision drives your deploy pipeline, not the library.
5. Roll out per resource; build the export/reporting path in parallel if custom data feeds anything outside Filament.
6. Enable the expensive flags last: encryption, multi-tenancy, conditional visibility, custom field types.

Operational Impact

Maintenance. Budget an upgrade cycle at every Filament major (roughly annual), plus a read of every changelog before minor bumps. Release cadence is high — seven patch releases in the 3.1.x line alone — which is healthy activity but also means frequent small surface changes. Track config/custom-fields.php diffs, since published configs do not receive new keys automatically (3.8.0 explicitly notes this and defaults safely; do not assume that holds forever).

Support. A commercial license is not automatically a support contract — confirm separately. Assume self-support for anything unusual, and expect GitHub-issue latency measured in days, not hours, on a single-maintainer project.

Scaling. The maintainer's 3.8.0 notes show EXPLAIN (ANALYZE, BUFFERS) benchmarking against a 50,000-row seeded tenant, which is a reassuring rigor signal. The structural concern is inherent to EAV, not to this implementation: custom-field sorting and filtering in Filament tables become join-heavy, indexes are on the value tables rather than tuned to your access patterns, and record-lookup fields need their order column indexed once lookup tables grow. If custom-field data feeds analytics or customer reporting, build a projection table rather than querying values live.

Failure modes to design against.

• Cross-tenant leakage from a tenancy misconfiguration — highest severity; write an explicit isolation test before enabling the multi-tenancy flag.
• Definition drift — deletions and type changes orphan values; restrict who can edit definitions and prefer deactivation (the package supports it) over deletion.
• Encrypted fields plus lost key equals unrecoverable data; document key custody and rotation before enabling the encryption flag.
• Upgrade gridlock — a Filament security release you cannot take because the package major has not shipped.
• Environment parity — definitions are runtime data, so staging and production diverge silently; add a definitions export/import step to your deploy pipeline.
• Late license discovery — finding the AGPL constraint after rollout forces a removal project or an unplanned purchase.

Ramp-up. A Filament-fluent developer is productive in under a day on the trait-plus-builder path. The learning curve sits in the feature flags (tenancy, encryption, sections, conditional visibility), the definition governance model, and any read path outside Filament. Docs exist on the project site plus an agent-oriented SKILL.md, which is a plus for onboarding, but licensing and tenancy edge cases should be verified directly against the maintainer rather than inferred from docs.