Nova Drafts Laravel Package

Technical Evaluation

• Architecture fit: Fits Laravel applications already using Nova as the editorial/admin surface, where resources need a draft-versus-published workflow. The package is an admin-layer convenience, not a general content-versioning platform; it is a poor fit for headless/API-first publishing, non-Nova admin UIs, or complex editorial workflows requiring approvals, scheduling, localization, or full version history.
• Integration feasibility: Feasible for a small number of Eloquent-backed Nova resources if the app’s Nova/Laravel/PHP versions are compatible. Expect model traits, migrations, Nova resource changes, policy/authorization review, preview behavior, and publish actions. Validate against relationships, file/media attachments, slugs, and localized fields before committing.
• Technical risk: High lifecycle risk. The package is archived, last released 2022-11-18, and has low adoption (29 stars). That means no upstream fixes, unclear compatibility with current Nova/Laravel releases, and dependency drift over time. Publishing semantics can create data-integrity risk: partial publishes, duplicate slugs, stale drafts, orphaned media, and permission leaks around previews. Treat it as a reference implementation or an internal fork candidate, not a long-term unowned dependency.
• Key questions: Which Nova, Laravel, and PHP versions are supported? Which database engines are validated? How are draft records linked to published records, and what happens on publish failure? Are previews authorization-scoped? How are relationships, media, localization, and nested resources handled? Is publishing transactional and concurrency-safe? Who owns a fork if adopted? What is the rollback path?

Integration Approach

• Stack fit: Best fit is a conventional Laravel + Nova monolith where editors work inside Nova and the draft workflow is limited to a few resource types. Weak fit if the roadmap includes Nova major upgrades, headless content delivery, or multi-team editorial governance.
• Migration path: Start with a sandbox proof of concept on one low-risk resource. Inventory candidate resources and fields, confirm schema changes are additive, backfill existing published records, gate the feature behind a flag, pilot with editors, then expand. If compatibility fails, fork the package internally or reimplement only the needed draft/publish pattern.
• Compatibility: Pin Nova, Laravel, PHP, and database versions in the PoC. Run a compatibility matrix across migrations, traits, Nova fields/actions, policies, file uploads, and relationship fields. Because the upstream is archived, prefer a vendored/forked dependency under organizational control rather than a floating Composer constraint.
• Sequencing: 1) confirm editorial use cases and ownership; 2) run a one-resource PoC; 3) review authorization, preview, and publish integrity; 4) define migration and rollback plans; 5) pilot with a small editor group; 6) expand resource by resource; 7) establish fork maintenance and upgrade testing before broad rollout. Run old and new workflows in parallel during the pilot.

Operational Impact

• Maintenance: Requires an internal owner from day one. Budget for dependency updates, security patching, Nova upgrade compatibility, and schema evolution. An archived package with no upstream support should be forked or wrapped behind an internal abstraction if adopted.
• Support: No vendor support channel. Editors will need runbooks for stuck drafts, failed publishes, duplicate slugs, preview access issues, and orphaned media. Engineering support rotation and clear escalation paths are necessary.
• Scaling: Draft records can roughly double storage for affected tables and add relationship/media duplication. Validate indexing, Nova table performance, publishing transaction size, and cleanup/pruning at expected content volume. Likely acceptable for modest editorial usage; risky for high-volume or highly relational content without tuning.
• Failure modes: Partial publishes, stale drafts diverging from published records, duplicate slugs, orphaned files, authorization gaps in previews, migration conflicts, and breakage after Nova/Laravel upgrades. Publish operations should be transactional and observable, with audit logging and rollback procedures.
• Ramp-up: Expect meaningful TPM/engineering time for PoC, compatibility testing, documentation, and editor training. A one-resource pilot may be feasible in a sprint or two; broader rollout and fork ownership require ongoing investment. Adopt only with explicit ownership and a fork/maintenance plan; otherwise use the package as a reference design.