Nova Publishable Laravel Package

Technical Evaluation

Architecture fit creode-modules/nova-publishable is a Laravel Nova extension that layers publish-state behaviour (draft/published) onto Eloquent resources and exposes it through Nova's UI. Architecturally it sits in the presentation/administration tier: it is a Nova tool, not a domain service, so it should not become the source of truth for publishing. Fit is good where publishing is a simple boolean/timestamp concern on a model and where Nova is already the back-office surface. It is a poor fit if publishing has workflow semantics (multi-stage approval, embargo windows, per-locale publishing) — those need to live in the application layer, not in a Nova field/tool.

The 1.2.0 release is a single, narrow change: Laravel 11 compatibility (PR #2, first contribution from @makowskid). That is a dependency-compatibility signal, not a capability change. Treat 1.2.0 as "this package is not abandoned in the L11 migration" rather than as new functionality.

Integration feasibility Low-to-moderate effort. It is a Composer package with an auto-discovered service provider and (typically) a Nova tool/field registration plus a migration or publishable config. Integration is largely: install, run migration/publish config, attach the field or trait to the target Nova resource, and confirm the underlying model columns. There is no evidence of a service layer, external API, or queue dependency, so the blast radius is confined to Nova request handling and the affected models.

The real feasibility question is matrix compatibility, which the release notes do not state. "L11 compatibility" could mean the illuminate/* constraints were widened (supporting L10 and L11) or replaced (L11 only, L10 dropped). That distinction determines whether 1.2.0 is a safe patch bump or a coordinated upgrade with the framework. This must be verified from composer.json before adoption planning.

Technical risk

• Version-matrix ambiguity (primary risk). Nova and Laravel version coupling is not documented in the notes. Nova 4 vs Nova 5 support, and whether PHP 8.2+ (an L11 prerequisite) is now required, are both unstated. A package that "supports L11" but pins an older Nova major will not install cleanly.
• Maintainer concentration. Two releases, one external contributor, a single PR for this change. Bus factor is effectively one. Mitigate with a fork-and-pin strategy rather than floating constraints.
• Test coverage unknown. No CI matrix or test evidence in the notes. A compatibility PR that touches only constraints may be untested against a real Nova install.
• Hidden coupling to Nova internals. Publish-state fields commonly hook Nova index queries, filters, and action visibility. These are the areas most likely to break silently across Nova majors.
• Semantics drift. If the package owns the published column and the application also writes to it, state can diverge with no error surfaced.

Key questions

1. Does 1.2.0 widen the illuminate/* constraints or replace them — is Laravel 10 still supported?
2. Which Nova majors are supported in 1.2.0, and what is the minimum PHP version?
3. Is there a CI matrix covering Nova/Laravel/PHP combinations, and did PR #2 run against it?
4. Does the package ship migrations, and are they additive or destructive to existing publishable columns?
5. Is publishing enforced at the model/trait level (query scopes) or only in the Nova UI? This determines whether a Nova-side change can affect public-facing content.
6. Are scheduled/embargoed publishes handled by the package or expected to be app-owned?
7. Who is the accountable maintainer, and is there a documented support or security-reporting channel?

Integration Approach

Stack fit Assumes Laravel + Nova on the admin surface. With 1.2.0 the package is now viable for teams on Laravel 11 — the common case for a current Nova 4/5 upgrade. Where the stack is still on Laravel 10, confirm 1.2.0 does not force an early framework bump; if it does, defer adoption until the L11 upgrade is scheduled, since a Nova admin package is not a reason to move the framework.

Migration path Sequence the framework first, package second:

1. Verify current pins: Laravel, Nova, PHP, and the installed nova-publishable version.
2. Inspect 1.2.0 composer.json constraints for Laravel, Nova, and PHP.
3. In a branch, run composer update creode-modules/nova-publishable --with-dependencies and record the resolved graph.
4. Exercise the publish/unpublish/unpublish-and-edit flows in a staging Nova instance against a copy of production data.
5. Confirm no new migrations are pending and that existing publish-state values survive (published_at/is_published intact, filters and index badges correct).
6. Roll out; keep the previous lock entry available for a one-command revert.

Compatibility Confirm the package's Nova constraint matches the Nova major actually installed — this is the likeliest install failure. Also verify PHP minimum (L11 requires 8.2) against CI images and any shared hosting. If the package still supports Laravel 10, keep the constraint bounded (^1.2) rather than unbounded, so a future major cannot drift in unreviewed.

Sequencing Do not bundle this with other Nova or framework changes. The change is a constraint widening with no feature surface, so it is a good candidate for a standalone low-risk PR — but it should land after the Laravel 11 upgrade is validated, not as part of it, so that if publishing behaviour regresses the cause is unambiguous.

Operational Impact

Maintenance Low ongoing code maintenance, but non-trivial dependency-watch overhead: the package must track both Laravel and Nova majors, and Nova's release cadence is faster than Laravel's. Assign explicit ownership for "who watches this package's releases" — an unowned Nova add-on is how admin tooling silently falls out of support. Budget a small recurring review each Nova major. Given the single-maintainer profile, maintain a fork-and-pin fallback in the team's dependency policy.

Support No documented commercial support, no visible issue-triage SLA, one contributor of record. Internal support means internal expertise: at least two engineers should be able to modify the field/tool behaviour, because upstream turnaround is not dependable. Capture the integration in the team's runbook rather than relying on upstream docs.

Scaling Negligible infrastructure impact — this is request-path admin code, not a background worker or data pipeline. Watch only for query cost on Nova index screens if the package adds publish-state filters or eager-loaded scopes to large tables; verify index coverage on the published column. Public read paths should not be routed through the package's scopes unless that has been deliberately confirmed, since coupling content delivery to an admin add-on creates an avoidable scaling constraint.

Failure modes

• Install-time failure (most likely): Nova or PHP constraint conflict during composer update. Loud, caught in CI, low impact.
• Silent publish-state regression: content that should be public becomes hidden or vice versa, with no exception raised. This is the highest-severity mode and is why staging verification on production-like data is mandatory.
• Nova UI divergence: field renders but writes are ignored after a Nova internal change. Caught by a scripted publish/unpublish smoke test, not by unit tests alone.
• Abandonment: upstream stops tracking Nova, forcing a fork. Low probability near-term (1.2.0 is fresh), high cost if it happens unmitigated.
• Ownership ambiguity: both the package and application code write the published column. Prevent by designating the package as sole writer within Nova and the application as sole writer elsewhere.

Ramp-up A developer familiar with Nova can integrate and verify this in under a day; the package surface is small. The cost is in validation, not configuration: allow an additional day for a staging pass covering publish, unpublish, scheduled/embargoed states (if supported), index filters, and access-control interaction. Document the resolved version matrix and the smoke-test steps in the repo — that artefact, not the package, is what makes future upgrades cheap.