wdelfuego/nova-wizard
Add multi-step wizards to Laravel Nova forms. nova-wizard splits long resource forms into guided, step-by-step flows, letting you group fields into panels and control navigation per step so complex admin forms stay simple and easy to complete.
Architecture fit. nova-wizard is a Laravel Nova 4 extension that re-frames Nova's single-page resource creation form as a multi-step flow. Architecturally it sits inside Nova's tool/field extension surface: a service provider, published assets, and custom Vue components that wrap Nova's native field rendering. For teams already standardized on Nova, this is a natural fit — it consumes Nova's resource/field definitions rather than replacing them, so the conceptual overhead is low. The risk is that Nova tools inherently couple to Nova's semi-internal frontend contracts, which are not part of Laravel's public API stability guarantee. Any package in this category inherits Nova's upgrade cadence (Nova 4 → Nova 5 migration is the obvious cliff).
Integration feasibility. High for the happy path, low-confidence everywhere else. Installation is standard Composer + vendor:publish, and the wizard is adopted per-resource, so it can be trialed on a single low-risk admin form. Feasibility breaks down on three fronts: (1) Nova itself is closed-source and license-gated, so the package's compatibility window is only as good as the maintainer's testing against Nova point releases; (2) the license is NOASSERTION, meaning no recognized OSS license was detected — this requires manual legal review before it touches production; (3) field coverage is unverified — complex Nova fields (BelongsTo search, File/Image, KeyValue, Repeater, custom fields) are exactly where multi-step wrappers tend to break because state is split across steps.
Technical risk. Concentrated and non-trivial:
NOASSERTION is a procurement blocker. It may be MIT with a malformed header, or it may be unlicensed (default all-rights-reserved). Must be resolved before evaluation deepens.Key questions. Is the license clarified in LICENSE/composer.json? Does it target Nova 4.x broadly or pin a specific point release, and is there a Nova 5 path? Does it support update/edit flows or create-only? How are per-step validation and server-side enforcement handled (client-only stepping is unacceptable)? Which Nova field types are verified, and how are file uploads and relationships handled across steps? Does every step honor Nova policies, canSee/canCreate rules, and resource-level authorization? Are there tests, and what is the commit cadence over the last 12 months?
Stack fit. Compatible with a conventional Laravel 10/11 + PHP 8.1+ + Nova 4 stack. It is additive: no database schema changes, no queue or infra requirements, and no impact on runtime services outside the Nova admin surface. For teams already paying for Nova, the marginal cost is one Composer dependency and a published asset set.
Migration path. Low-risk and reversible, which is its main appeal. Adopt per-resource rather than globally — pick one complex create form (many fields, high abandonment) as the pilot. Existing single-page Nova create screens remain untouched for all other resources, so there is no big-bang cutover. Rollback is composer remove plus deleting published assets and reverting the resource class; the blast radius is confined to the pilot resource. This makes it a good candidate for a time-boxed spike rather than a committed roadmap item.
Compatibility. Pin the package and Nova to exact versions and record the tested matrix in the repo. Because Nova is closed-source, compatibility cannot be inferred from semver; it must be verified by running the pilot against the specific Nova build in use. Treat "Nova upgrade" as a gated change requiring a wizard regression pass.
Sequencing. (1) License and provenance clearance — hard gate. (2) Source review by a senior Laravel dev, focused on authorization, validation, and endpoint exposure. (3) One-sprint spike on a non-critical resource with representative field types. (4) Verify per-step validation is enforced server-side, policies are honored, and file/relationship fields behave. (5) If green, roll out to the highest-value create form and measure completion rate and validation-error rate. (6) Record an internal ownership decision: adopt as-is, fork-and-maintain, or build a thin in-house equivalent on Nova's native extension points.
Maintenance. The dominant operational cost. With one maintainer, no dependents, and sparse stars, assume you will eventually own the code. Budget for a fork-and-vendor posture from day one: vendor the source, add it to the internal dependency register, and assign a named owner. Do not let it become an undocumented transitive dependency on a critical admin flow.
Support. No SLA, no commercial backing, community-only issue response. Internal documentation and a runbook are mandatory, particularly covering which resources use the wizard and how to disable it in an incident.
Scaling. Negligible infrastructure impact — it is a UI composition layer over existing Nova endpoints. Long multi-step forms with file uploads may increase request payload sizes and, if draft persistence exists, add write volume; neither is material at typical admin-panel traffic.
Failure modes. (a) Nova upgrade silently breaks wizard rendering or submission; (b) a Nova field type fails to render or loses state between steps, producing corrupt submissions; (c) client-side-only step validation allows invalid data to reach the server — the most serious class of failure; (d) custom endpoints bypassing Nova policies create an authorization hole; (e) package abandonment leaves an unpatchable security surface in an admin-authenticated area. Mitigations: pin versions, add a smoke test for the pilot resource to CI, and audit the wizard endpoints against Nova policy behavior before rollout.
Ramp-up. Low for developers already fluent in Nova and Vue — likely half a day to a day to read the source and stand up the pilot; slightly longer if the vendor documentation is thin, which is common at this maturity level. The real ramp-up cost is organizational, not technical: legal review, dependency registration, and the ownership decision. Given a composite score of 0.51 and high opportunity signal (11.72), the package addresses a genuine gap — Nova's native create form does not handle long forms well — but its maturity and licensing posture mean it should be treated as a prototype-grade dependency to spike, not a production commitment, until license and maintenance ownership are resolved.
How can I help you explore Laravel packages today?