Filament Content Builder Laravel Package

Technical Evaluation

Assessment basis: Initial evaluation triggered by v2.7.0. Evidence is limited to the release notes; no source review, composer.json inspection, or prior assessment exists. Treat conclusions as directional until a code and dependency audit is completed.

Architecture fit. This is a Laravel package with a Filament admin-panel plugin surface. The v2.7.0 feature — visible() / hidden() methods on blocks — aligns with Filament’s existing visibility conventions and extends the package’s block-composition model with per-block conditional rendering. For teams already using Filament for content authoring, this is a natural fit: blocks remain the unit of composition, and visibility becomes a first-class property rather than a custom workaround. The architectural coupling is to Filament’s schema/component lifecycle, so the package’s value is high inside a Filament panel and near zero outside one.

Integration feasibility. Likely a standard Composer install plus plugin registration in a panel provider, with optional config and migration publishing. v2.7.0 is a minor release and appears semver-compatible: one feature plus CI/dependency chores. The main feasibility unknown is the supported Filament major-version matrix. The removal of van-ons/filament-field-library is listed as a chore but is the highest-risk line in the release — if any consumer code or custom block relied on that package transitively, removal could surface as class-not-found at runtime despite the minor version bump.

Technical risk. Low for the release itself; moderate for the integration surface.

• Low: No breaking changes are announced; dependency bumps are confined to GitHub Actions (release-drafter, setup-php, label-sync), not runtime libraries.
• Moderate: Filament major-version coupling. Filament’s v3→v4 transition changed APIs; plugins often lag. Confirm the package’s constraint before committing.
• Moderate: Semantics of hidden(). Does a hidden block persist in the database and get filtered at render, or is it excluded at query time? This determines whether hidden content is a data-retention or information-exposure concern.
• Low–moderate: Transitive dependency removal (see above).

Key questions for the maintainer or code review:

1. Which Filament and Laravel versions are supported in composer.json, and is there a CI matrix proving it?
2. Do visible() / hidden() accept closures, booleans, and authorization checks — or only static booleans?
3. Is hidden state persisted, and is hidden content excluded from rendered HTML and API responses?
4. Was van-ons/filament-field-library a runtime dependency or dev-only? Does its removal change the public API?
5. Are blocks stored as JSON on a model, in a separate table, or both? What are the query characteristics at scale?
6. Is there a documented upgrade path from the prior minor, and are migrations required for v2.7.0?

Integration Approach

Stack fit. Best suited to Laravel 10/11/12 applications running Filament v3 or v4 admin panels that need structured, block-based content authoring — marketing pages, CMS-lite sections, configurable landing pages. It is not a fit for API-only services or teams standardized on Nova or custom Livewire admin surfaces. Confirm the Filament constraint first; that is the gating check.

Migration path.

1. Spike in a branch: composer require the package at ^2.7, register the plugin in the target panel provider, publish config and migrations.
2. Diff composer.lock specifically for the removed field-library package and any transitive changes; run the full test suite and a production-like asset build.
3. Exercise the new visibility methods on a single non-critical block type before broad adoption.
4. Roll out to staging with representative content, then production. Because this is a minor release, no data migration is expected — but verify by inspecting published migrations rather than assuming.

Compatibility. Pin to ^2.7 and treat Filament major upgrades as separate, planned workstreams. If the application is on Filament v4, verify the package explicitly supports it; do not infer from a green CI badge alone. Check PHP version constraints against the platform’s runtime.

Sequencing. Dependency audit → version constraint confirmation → dev-environment spike → visibility feature pilot → staging validation → production. Run the dependency audit before the spike; the field-library removal is the one item that could invalidate the rest of the plan. Budget one to two engineering days for the spike and half a day for the lockfile and CI review. TPM decision point after the spike: adopt, adopt-with-constraints, or defer pending maintainer clarification.

Operational Impact

Maintenance. Low ongoing burden. The project shows healthy maintenance signals — Dependabot automation, release-drafter, label-sync, an active maintainer, and a numbered PR/issue workflow. The cost is routine: periodic minor bumps, lockfile hygiene, and a Filament-major watch item. Assign a named internal owner; do not rely on the OSS maintainer for upgrade guidance.

Support. Community-supported open source with no SLA. Escalation path is GitHub issues and the maintainer’s responsiveness, which is not a contractual commitment. For business-critical content surfaces, plan a fork-or-vendor contingency and keep the integration surface small enough to patch locally.

Scaling. Rendering cost scales with block count per page. Hidden blocks are the specific concern: if visibility is evaluated at render time after hydration, hidden blocks still incur query and hydration cost and may leak into HTML if templates are careless. Mitigate with query-level filtering where supported, response/block caching, and an explicit check that hidden content is absent from serialized output. Confirm behavior under eager-loaded relations and multi-tenant scoping before high-traffic rollout.

Failure modes.

• Filament major upgrade breaks plugin boot or schema registration — highest-likelihood failure.
• Removed van-ons/filament-field-library causes class-not-found for custom fields in downstream code.
• hidden() semantics misunderstood: content still present in DOM, JSON payloads, or API responses.
• Migration drift if published migrations are edited locally rather than re-published.
• Unpinned minor versions pulling an unexpected change into production on the next composer update.

Ramp-up. Low for developers already fluent in Laravel and Filament; the block model and visibility API are idiomatic. Budget roughly half a day for a Laravel/Filament developer to read the docs and build a working example, plus the spike time above. TPM-facing documentation should capture the visibility contract — what “hidden” guarantees and does not guarantee — because that is the detail most likely to be misread by content and security stakeholders.

Recommendation. Proceed to a time-boxed spike at ^2.7, gated on two checks: confirmed Filament version support, and a clean lockfile diff for the removed field-library dependency. The visibility feature is genuinely useful for content operations and scheduled/feature-flagged sections, but the release notes alone are insufficient to approve broad adoption.