Laravel Filament Publishable Laravel Package

Technical Evaluation

Architecture fit. This is a thin UI adapter, not a standalone library. It binds Filament form/table components to the state machine and columns defined by novius/laravel-publishable (publication_status, published_at, expired_at). That's a clean separation: domain semantics live in the parent trait, presentation lives here. Architecturally it fits any Filament 4 admin panel already built on Eloquent resources, provided the parent package is the source of publication truth. If the team hasn't committed to novius/laravel-publishable, this package is an add-on to a dependency you must also adopt — evaluate the pair, not the package alone.

Integration feasibility. Low effort on the happy path. composer require, then drop five components into a resource's form(), table(), filters(), and bulkActions(). No migrations, no config, no service provider registration surfaced in the README. The real integration work is elsewhere: confirming the parent trait is installed on target models, verifying column names match, and adding authorization around the publish action (Filament policies gate the resource, not publishing specifically). Expect roughly a sprint-day for a first resource end-to-end, wrapping as you go.

Technical risk.

• Maturity: 4 stars, 0 dependents, single-maintainer profile, no commercial support. Treat as pilot-grade, not platform commitment.
• Documentation quality: The README ships at least two real bugs — PublishedFirstAt::make('expired_at') binds the wrong column, and the lang-publish command references a Nova-era provider class. The src/ directory is the source of truth; budget a verification spike.
• Version coupling: Filament 4 and Laravel 11 are hard floors and both are moving targets. Any Filament major upgrade becomes a coordinated task.
• License: AGPL v3 is a legal gate, not a technical detail. Incompatible with many proprietary/SaaS distribution models; may be fine for internal tooling. Get sign-off before writing code.
• Coverage ceiling: No approval chains, role-gated publishing, audit trails, publish-triggered side effects, or partial-failure handling in bulk operations. Anything beyond conventional status/date UX is extension work.

Key questions.

• Is novius/laravel-publishable already adopted, or is this a joint adoption decision?
• Does legal clear AGPL v3 for our distribution model?
• Who owns the wrapper that keeps these components replaceable?
• What's the acceptable behavior when the bulk publish action partially fails?
• How are publish side effects (cache, notifications, webhooks) supposed to fire — and do they fire under bulk operations?
• Is the 2026-05-12 release date verified against actual Packagist tags?

Integration Approach

Stack fit. Requires Laravel ≥ 11, PHP ≥ 8.2, Filament ≥ 4. Fits cleanly into a modern Filament admin panel with no infra changes, no new services, no data-model changes beyond what the parent trait already implies. It is a pure Composer dependency in the application layer.

Migration path. There is no migration in the data sense — the parent package owns schema. The integration path is:

1. Confirm parent trait installed on target models with the expected columns.
2. Add form fields to one resource.
3. Add the PublicationColumn and PublicationStatusFilter.
4. Add the PublicationBulkAction.
5. Publish lang files if the panel serves non-English editors (use --tag=lang; the README's provider class is wrong).
6. Roll to additional resources only after the first is stable.

Pre-existing publication state (if any) lives in the parent's schema; this package doesn't move data.

Compatibility. Pin the package in composer.json. Treat Filament major upgrades as coordinated work items that include a compatibility check on this package, not incidental composer update events. The parent and this adapter should move in lockstep; check parent release notes before bumping either.

Sequencing.

• Legal/licensing gate first — this can kill the initiative before any sprint time is spent.
• Parent-trait readiness second.
• One-resource pilot third, wrapped in local App\Filament\Components\Publish\* classes (~30 lines) so replacement is a one-directory swap.
• Broader rollout last, only after the pilot has run against realistic row counts and edge cases (timezone boundaries, bulk partial failures, role gating).

Wrapping is non-negotiable for a package this thin and this low-adoption. Skip the wrapper and future replacement becomes a search-and-replace across every resource.

Operational Impact

Maintenance. Low code footprint but non-zero maintenance load. Expect: occasional version bumps coordinated with Filament upgrades, ongoing reliance on a single maintainer for fixes, and the parent package's release cadence as the real dependency. The thin wrapper is the primary insurance policy — it converts "abandoned package" from an emergency into a contained swap.

Support. No commercial support, no SLA, no active community. Internal Slack-channel support is on the team that adopts it. Documentation drift (the README bugs) means onboarding relies on the vendor source, not the docs — that's a real ramp-up cost, not a formality.

Scaling. The UI surface scales trivially — forms and columns are cheap. The scaling risk is the bulk action. Verify before rollout: does it issue per-record save() calls or a single update? Does it dispatch model events? Does it wrap in a transaction? Partial failures without per-row feedback are the classic failure mode. Run against a few hundred rows with query logs on. Also confirm that any publish side effects implemented in observers fire consistently between single-record publish (from the edit page) and bulk publish (from the table); divergent behavior there is common and confusing.

Failure modes.

• Silent no-op fields — model missing the trait, column missing, or field name mismatch (the README's own example gets this wrong). Diagnose model-first, vendor-source-second.
• Version-drift breakage — Filament upgrade lands before the adapter catches up; resources break at render time.
• Bulk operation partial failure — some rows publish, some don't, no per-row feedback to the operator.
• Authorization gaps — an editor who can edit a post can also bulk-publish it because the policy gates the resource, not the action.
• Timezone / boundary ambiguity — "publish now" may not appear immediately if the parent evaluates state on a schedule; UI honesty depends on parent behavior.
• License surprise — discovering AGPL incompatibility after the pilot is sunk cost.

Ramp-up. Hours for a developer already fluent in Filament and Eloquent; effectively zero new concepts beyond the parent package's state machine. The ramp-up cost is not learning the API — it's learning to distrust the README, verifying component behavior against src/, and establishing conventions (authorization, side effects, wrapper) before the first rollout. Budget a short spike for the first resource to confirm the five components behave as expected in the actual panel; every subsequent resource is a copy-and-adjust exercise.