Laravel Nova Stubs Laravel Package

Product Decisions This Supports

• Build vs. buy — resolved toward "build (in-house, ~1 hour)" rather than adopt. The capability is small and static: a set of publishable stub templates plus a service provider that registers them for Nova's nova:resource, nova:filter, nova:lens, and similar Artisan generators. We can copy the stubs into our own repo and register them ourselves, which removes an external dependency for a feature we would otherwise have to fork anyway.
• Engineering-standards / code-consistency roadmap. The underlying value is real and cheap: generated Nova boilerplate that matches our conventions (namespace layout, base classes, docblocks, declare(strict_types=1), DTO/action wiring) instead of Nova's stock templates. That reduces review churn on every new Nova resource and makes scaffolding worth using for junior engineers.
• Developer-experience investment sizing. This is a "small, focused, no-runtime-overhead" dev-tooling item — it never ships to production and cannot affect runtime behavior or performance. It belongs in a DX/ergonomics bucket, not in a platform or risk-reduction bucket, and should be scoped accordingly (an afternoon, not a sprint).
• Dependency policy / technical-debt register. The package is archived, the last release was 2020-11-30, and it has 1 GitHub star. That is a "don't take a dependency on it" signal regardless of code quality. Any adoption path must be vendored copy with a named internal owner, not a Composer require line.
• Nova upgrade planning (Nova 3 → Nova 4+). Nova 4 materially changed generated class structure and its generator commands. Stubs pinned in 2020 will produce code that is stale for current Nova. If we touch this at all, the decision point is "regenerate our stub set against the Nova version we actually run," which is a task on the Nova upgrade epic — not a package decision.
• Use cases where it matters: teams standardizing Nova admin code across multiple apps; teams generating many resources/lenses/filters; anyone who has previously edited files inside vendor/laravel/nova to change output (that workaround should be replaced by an owned stub set).

Caveat: the prior assessment notes in this thread describe a PHP 8 runtime-modernization story. That is the 2.1.0 release note of an archived 2020 package and does not reflect current reality — treat those notes as superseded by this one.

When to Consider This Package

Consider adopting the idea, not the package, when:

• You run Nova 3.x and generate resources/filters/lenses frequently enough that stock boilerplate causes recurring review comments.
• You have a house style for Nova classes (namespaces, base classes, strict types, action/DTO conventions) worth encoding once.
• You want a bounded, low-risk DX win with zero production surface area.

Look elsewhere — and specifically do not add this as a dependency — when any of the following is true:

• You are on Nova 4 or later. The package predates Nova 4; stub content and generator expectations will not match. This is the most common disqualifier.
• You are on current Laravel/PHP (8.2/8.3). The last release (2020-11-30) added PHP 8.0 support and nothing since; there is no evidence of support for later runtimes, and no maintenance to fix it.
• You require any support commitment. Archived repos get no CVE response, no compatibility patches, and no issue triage. An abandoned dependency in the build toolchain is still supply-chain surface.
• You are the only consumer. At 1 star there is essentially no community to benefit from bug reports; you would be the maintainer in practice.
• A one-off need. If you only occasionally generate Nova classes, editing output by hand is cheaper than owning stub infrastructure.

Due diligence before any use (recommended path: fork/vendor, not require):

• Diff the package's stubs against the stubs shipped by your current Nova version and confirm the delta is still meaningful.
• Confirm the publish/registration mechanism still works with current Nova generator commands.
• Assign an internal owner and record the stub set as an owned artifact in our repo, with a note to revisit on each Nova upgrade.
• If we still choose to depend on it, verify PHP/Laravel/Nova constraints in composer.json and confirm it resolves cleanly against our lockfile.

How to Pitch It (Stakeholders)

For executives: this is a very small developer-tooling package that lets our engineers customize the code Laravel Nova generates automatically, so new admin screens follow our internal standards from the first commit instead of being hand-cleaned in code review. The value is modest and purely internal — it never touches production. The important finding is that the package itself is archived and unmaintained since 2020, so my recommendation is not to take it as a dependency. Instead, we copy its small set of templates into our own repository and own them. That captures the entire benefit — consistent generated code, less review churn — with no abandoned third-party dependency, no security-response gap, and no upgrade risk.

For engineering: the package is just publishable Nova generator stubs plus a registration hook — no runtime code, no production footprint. Two facts decide this: it was archived and its last release was 2020-11-30 (adding PHP 8.0 support, nothing since), and it predates Nova 4's changes to generated class structure. Requiring it would pin us to stale templates and hand us an unowned dependency. Recommendation: vendor the stub files into our repo, register them ourselves for the Nova generators we use, and regenerate the set against our current Nova version as part of the Nova upgrade work. If someone still wants the Composer dependency, they need to show a diff of its stubs versus current Nova's, confirm resolution against our lockfile, and name an owner — but I do not expect that to be worth it.