Laravel Nova Helpers Laravel Package

Getting Started

This is a utility/helper package for Laravel Nova — it does not ship a UI of its own, so the fastest way to judge it is to read the source tree rather than the README.

1. Install and lock a version:

   composer require mphpmaster/laravel-nova-helpers:^1.2
   

   Verify the exact vendor string on Packagist before running this; mPhpMaster packages have historically been published under slightly different casing (mphpmaster, mphp-master), and a wrong name silently sends you to an unrelated package.
2. Confirm discovery: check composer show mphpmaster/laravel-nova-helpers for an auto-discovered service provider. If one is listed, no manual registration is needed; if the package ships a config file, publish it (php artisan vendor:publish --provider=...) before your first config:cache, otherwise the defaults get baked in.
3. Look first at src/ for Traits/, Helpers/ (or helpers.php), and any Macros/ directory. Those three locations tell you what the package actually changes in your app — the README is usually thin, the source is the documentation.
4. First use case: pick one Nova Resource with repetitive field definitions (timestamps, BelongsTo selects with the same ->searchable() / ->sortable() chain, status badges). Apply a single trait or macro from the package to that one resource, verify the generated form/index still renders, then roll it out. Do not convert the whole app/Nova directory on day one.

If the package turns out to be mostly global helper functions and Nova macros, treat it as a "convenience layer" and evaluate it on how much boilerplate it removes per resource — not on feature count.

Implementation Patterns

Trait-on-Resource composition. The dominant pattern for Nova helper packages is traits you use inside a Nova\Resource subclass. Keep your own app/Nova/Resources/BaseResource.php (or a Concerns/ folder) as the single place those traits are applied, and let concrete resources extend it. This means a future major version only touches one file.

Macros as opt-in. Nova macros registered by the package are global — they attach to Nova\Fields\Field, Nova\Fields\Text, or the Nova facade. Apply them deliberately at call sites rather than aliasing them into your own wrappers immediately; if the macro is renamed or removed, a grep for the macro name across app/Nova is your entire migration.

Resource bootstrapping for repeated field bundles. For fields that always appear together (created/updated timestamps, an ID field, an author BelongsTo), a method that returns array_merge($this->baseFields(), [...]) is more predictable than relying on traits to mutate fields(). Nova's fields() contract is a plain array — keep it explicit so nova:resource scaffolding and IDE navigation still work.

Filters, actions, and metrics. If the package supplies base classes for these, extend them rather than using them directly. Nova resolves actions and filters by class name and serializes them across the request boundary, so keeping your own subclass gives you a stable class name and a place to override behaviour.

Integration with existing helpers. mPhpMaster publishes several overlapping helper packages (laravel-helpers, model helpers, this one). Before adopting a function here, check it is not already provided by another package in your composer.json — duplicate global function declarations are a fatal error at autoload time, not a warning.

Testing. Assert on Nova's JSON payloads ($this->get('/nova-api/users')) rather than on the trait internals. Helper-driven field definitions are effectively untested by unit tests; a single feature test per resource that hits the index and detail endpoints catches most breakage from a version bump.

Gotchas and Tips

• Release notes are not a changelog. The 1.2.0 entry is literally just a compare URL (1.1.0...1.2.0) with no described changes. Before upgrading, read the diff directly at that link and pay attention to composer.json (illuminate/*, laravel/nova constraints), any deleted files, and any renamed trait methods. A minor version bump on a helpers package can still be breaking because traits are inherited into your classes.
• Nova is not on Packagist. Nova requires a private repository credential. If composer update fails while resolving this package, it is almost always the Nova constraint, not this package.
• Nova major-version drift. Nova 4 → 5 changed several field and filter signatures. Pin this package to a version whose composer.json Nova constraint matches yours; "helpers" packages are frequently updated for one Nova major only.
• Global function collisions. If the package loads a helpers.php via files autoload, functions are defined unconditionally in the global namespace. Use composer dump-autoload -o after install and watch for Cannot redeclare function fatals — the error names the conflicting package.
• Config caching. Any config() call made inside a helper at boot time is evaluated once. Run php artisan config:cache in a staging environment before deploying, or you will discover the problem in production.
• Debugging macros. When a macro misbehaves, verify registration order: macros registered in a service provider's boot() run after Nova's own field setup. Use php artisan tinker and Nova\Fields\Text::hasMacro('name') to confirm the macro exists at all before chasing the implementation.
• Extension points. Prefer your own subclass over Nova::macro() for anything you plan to keep long-term — you control the namespace and the signature. Reserve direct use of the package's macros and helpers for code you are comfortable rewriting on a minor upgrade.
• Exit ramp. Because this is a helpers package, removal cost equals grep effort. Keep usage concentrated in a base resource class and a few traits so a future swap-out is a mechanical change rather than an audit of every Nova class.