- What is norman-huth/nova-basic-package used for?
- It is a Laravel Nova package scaffold by Norman Huth: the service provider, tool registration, asset pipeline, and test-harness skeleton you copy when starting a new Nova tool, card, or resource tool. It is not a runtime library, so its value is entirely time-to-first-working-tool and convention enforcement across a Nova codebase. Teams that build multiple custom Nova extensions and lack a house standard are the intended audience.
- How do I install norman-huth/nova-basic-package?
- Mechanically it installs like any Composer package, but adoption requires a licensed Nova installation plus a private registry or path repository in CI before the scaffold can even be smoke-tested, because Nova itself is a paid private dependency. The evaluation's recommended pattern is to vendor the repository into an internal template repo and publish it as a Composer create-project template or git subtree seed rather than requiring it from Packagist.
- Which Laravel Nova and PHP versions does this package support?
- The evaluation does not confirm the constraints and explicitly flags that you must read composer.json to see which Nova and PHP versions it actually pins. Nova major-version drift from 4 to 5 and Vite/Mix shifts is rated a high risk because the repo is archived and will not receive compatibility bumps. Confirm your target is Nova 4 or 5 era before adopting, since anything older turns this from a starter into a rewrite.
- Is norman-huth/nova-basic-package still maintained?
- No. The repository is archived and has zero stars and zero dependents, meaning no upstream maintenance, no issue triage, and no security response. You would be adopting an unexercised artifact and, once forked, you own 100 percent of the code forever. Assign a named internal owner before any commitment.
- What are the risks of using this scaffold in production?
- The dominant risk is the archived status combined with zero adoption, so asset compilation, publish tags, and autoload config are unproven in the wild. Nova major-version drift is rated high severity, and the anomalous last-release date means you should verify provenance and tag contents before trusting any version pin. Adopt it as an internal template with an owner rather than as a live Composer dependency.
- Does it include a working test harness and CI configuration?
- The technical evaluation lists this as an open question: the scaffold may ship an Orchestra Testbench, Pest, or PHPUnit harness with CI, or only directory stubs. Check the repository before committing, because a scaffold without a working test harness undercuts the main reason to adopt one. If stubs are missing, budget roughly three to five days of hardening.
- Does it use Vite or Laravel Mix for the front-end assets?
- This is also flagged as unverified in the evaluation, so inspect the package to determine whether it uses Vite or Mix. That matters because the front-end pipeline must match the build you already run in CI, otherwise the scaffold adds friction instead of removing it. The Nova 4 to 5 Vite/Mix shift is itself called out as a high risk for archived skeletons.
- Does it scaffold tools, cards, and resource tools, or only one variant?
- The evaluation does not confirm which variants are included, so check whether the scaffold covers tool, card, and resource tool stubs or just one. If it covers only one, the convention-enforcement benefit shrinks and the delta versus official stubs narrows. Run a two-to-three day spike generating one throwaway Nova tool end-to-end to see what actually works.
- How does it compare to Laravel Nova official stubs or a hand-rolled skeleton?
- The evaluation asks for exactly this delta: if it is small relative to the official laravel/nova-* stubs or a hand-rolled two-hundred-line skeleton, the fork is not worth the ownership. The package's pitch is that it encodes the Nova contract points teams get wrong, such as provider registration, route and middleware wiring, and publishable config and migrations. Measure that claim against the official stubs before adopting.
- Can I fork and re-namespace it for internal use?
- Yes. It is MIT licensed, so forking, re-namespacing, and internal distribution are unencumbered, and there is no transitive footprint or downstream consumer to coordinate with. The tradeoff is fork divergence: once forked, upstream improvements can never be reconciled, so you own the code and must name an owner. Publish it internally as a create-project template or git subtree seed.