Nova Defaultable Laravel Package

Product Decisions This Supports

• Back-office UX investment and time-to-create. Nova Defaultable pre-fills create forms with sensible starting values — status = draft, owner = current user, publish_at = now + 1 day — so operators stop retyping the same boilerplate on every record. The decision it informs: is shortening time-to-create for core admin records worth engineering time this quarter, and which fields should never be blank? v1.2 extends the same mechanism into resource action modals, which changes the answer for confirmation-style flows: "Assign to…", "Duplicate as draft", and "Move to status" can open on the intended value so an operator confirms in one click instead of filling a form.
• Build vs. buy vs. copy the pattern. This is not a strategic capability — it is a thin trait plus service provider over standard Nova field definitions. The genuine PM decision is which of three paths to take: adopt the package, vendor/fork the MIT-licensed trait into app/Nova/Concerns/, or skip it and use ->withMeta(['value' => ...]) alongside model $attributes and database defaults. Frame it as "a few days of admin polish" rather than a platform dependency, and budget accordingly.
• Where business defaults live (single source of truth). Defaults encode rules: which status a record starts in, who owns it, what dates are auto-set, what an action's initial payload should be. Once create forms and action modals both consume defaults, silent divergence between the two surfaces becomes the failure mode — a new record starts as draft but the "Move to status" action defaults to published. Decide deliberately whether defaults are centralized in a defaults() helper on the resource, in model $attributes, or in migrations, and make that the reviewable convention.
• Roadmap placement. This belongs in a backlog item like "reduce admin data-entry errors" or "standardize record creation," sized small. It is not a platform initiative, and it should not consume a dependency-risk line item unless the blast radius is genuinely contained.
• Dependency risk budgeting. 51 stars, 0 dependents, a long gap in releases, and a single v1.2 revival. That is evidence of activity, not evidence of maintenance. The PM call is to evaluate the category (Nova form and action defaults) while declining the specific artifact as a long-lived dependency wherever it touches critical operator workflows.

When to Consider This Package

Consider it — as an accelerant, pattern reference, or internal-only utility — when:

• You are on a Nova version compatible with the package's supported range and want field-level defaults on both create forms and resource action modals with minimal effort. That combination is narrower than plain model defaults and is exactly what this package targets.
• The app is internal-only or throwaway, where an unmaintained dependency is acceptable because the blast radius is small and the admin UX payoff is immediate.
• You want to read a compact, working implementation of Nova defaulting before writing your own — the trait is short enough to read end-to-end, and that readability is the real deliverable.
• You are evaluating defaultLast() as a design idea (fallback-only semantics). The release notes flag it as carrying a caveat/workaround, so treat it as something to inspect and test, never as behavior to depend on.

Look elsewhere — or implement in-house — when:

• You are on current Nova or Laravel. The package's center of gravity is the 2019-era API; a v1.2 release confirms someone is touching it, not that it installs cleanly on your stack. Verify against your exact version before committing, and prefer a forked path repository with a widened constraint over --ignore-platform-reqs in CI.
• You need maintenance guarantees, security patching, vendor support, or predictable releases. None of those exist here.
• Records are also created outside Nova — seeders, imports, APIs, queue jobs. Package defaults are render/request-time conveniences; hidden fields never persist. Real database defaults and model $attributes must still carry the business rule.
• You would be stacking default() / defaultLast() with withMeta(['value' => ...]), resolveUsing(), or fillUsing(). Last writer wins — pick one convention per field instead of hoping precedence resolves in your favor.
• You need defaults inside queued or standalone actions, where there may be no meaningful request or authenticated user for a closure default to read.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed add-on for the internal admin tool that pre-fills new-record forms and action dialogs with the values we already know — the default status, the assigned owner, the effective date. It removes repetitive typing from high-frequency operator workflows, which reduces data-entry errors and speeds up record creation, and the latest version extends that to the one-click action flows our support team lives in. It is not a platform bet: the capability is a few hundred lines of code, so we can adopt it, copy it in-house, or replace it outright at negligible cost. The decision I need is whether admin ergonomics is worth a small, time-boxed backlog item this cycle — not whether to take on a vendor.

To engineering: Treat this as a convenience we own, not a dependency we rely on. It is a single trait plus a service provider, last meaningfully released in 2019 with a v1.2 that added action support; 51 stars, zero dependents, sporadic cadence. Pin ^1.2 (older constraints silently skip action defaults), read the vendored trait source rather than the README to confirm the method names and precedence your installed version actually exposes, and plan the exit up front: copy the trait into app/Nova/Concerns/Defaultable.php with identical call sites, or drop it for withMeta(['value' => ...]) plus model-level $attributes. Keep one source of truth for defaults across create forms and action modals, allow exactly one of default()/defaultLast() per field as a code-review rule, keep real database defaults for anything created outside Nova, and cover three test cases — new resource, existing resource, action modal — so we catch "defaults leaked into edit" and "modal opened blank" regressions before operators do.