Laravel Nova Price Field Laravel Package

Getting Started

This 4.0.1 release is the Nova 4 line of the package. Treat it as a compatibility branch rather than an incremental patch: if you are still on Nova 3, stay on the 3.x releases; if you are on Nova 4, this is the version to install.

Minimal setup:

composer require <vendor>/<package>:^4.0
php artisan vendor:publish --provider="<Vendor>\\<Package>\\<Package>ServiceProvider"
php artisan migrate   # only if the package ships migrations

Register the package's Nova integration in app/Providers/NovaServiceProvider.php:

public function tools()
{
    return [
        new \Vendor\Package\PackageTool,
    ];
}

Then look first at:

1. The package's src/ directory — the Tool, Card, or Field classes you will reference from your Nova resources.
2. config/<package>.php — the published config file is the fastest way to understand available options.
3. resources/js/ and resources/views/ — for tool/card packages, the front-end entry points tell you what is customizable.
4. The package README's Nova 4 section — confirm asset build steps and any changed namespaces.

First use case: add the package's field or tool to a single Nova resource, verify it in php artisan nova:dev or your local Nova install, then roll it out to the rest of your resources. Keep the first integration small so you can isolate Nova 4-specific issues from your own resource configuration.

Implementation Patterns

Register once, reference everywhere. Nova tools are registered in NovaServiceProvider::tools(), while fields/cards are referenced inside resource fields() methods. Do not confuse the two: a tool registration mistake will not surface until the Nova dashboard loads, whereas a field mistake fails on the resource index.

Compose fields in resource definitions. A typical Nova 4 resource usage:

public function fields(NovaRequest $request)
{
    return [
        ID::make()->sortable(),
        Text::make('Name')->rules('required', 'max:255'),
        \Vendor\Package\SomeField::make('Status')
            ->options([...])
            ->displayUsing(fn ($value) => Str::headline($value)),
    ];
}

Keep package-specific field configuration in the resource rather than in a global config where possible; it makes per-resource behavior explicit and easier to test.

Use Nova 4's fields(NovaRequest $request) signature. Nova 4 moved from fields(Request $request) to NovaRequest. If you are porting resources from Nova 3, update the type hints as you touch each resource — mixed signatures cause confusing resolution errors.

Asset registration. For tools and custom fields that ship JS/CSS, Nova 4 expects assets registered through the tool's boot() method or the service provider:

Nova::script('package-tool', __DIR__.'/../dist/js/tool.js');
Nova::style('package-tool', __DIR__.'/../dist/css/tool.css');

Run the package's build (npm install && npm run prod) after publishing if the dist assets are not included in the release.

Authorization. If the package exposes actions or tools, wire them to Laravel policies and Nova's canSee/canRun methods. Nova 4 authorization runs through the same gates as the rest of the app, so policy changes apply immediately without package-level config.

Testing workflow. Use Nova's testing helpers (Nova::actingAs()) to cover resource screens that use the package. For field-level logic, unit test the field's resolve/displayUsing callbacks directly rather than booting a full Nova request.

Local development loop. When modifying package views or assets, publish them into your app (vendor:publish --tag=<package>-views) and iterate locally; keep the vendor copy as the reference for upgrades.

Gotchas and Tips

Version constraint mismatch is the most common failure. Nova 4 requires a modern Laravel/PHP baseline (Laravel 9+/PHP 8.0+ in most cases). Composer will resolve the package but Nova itself will fail at runtime if your app is on an older framework. Check composer why-not laravel/nova when in doubt.

Nova 3 to Nova 4 is a breaking jump. This release is explicitly a Nova 4 build. Do not assume the 3.x API carries over: field method signatures, asset handling (Mix to Vite in many packages), and tool bootstrapping changed. Port one resource at a time.

Clear caches after every upgrade. Nova caches tool and field metadata aggressively. After composer update and publishing, run:

php artisan config:clear
php artisan view:clear
php artisan route:clear
php artisan nova:publish

A stale compiled view or cached config is the usual cause of "my new field doesn't appear" or "tool renders blank."

Re-publish assets after upgrading. Published JS/CSS and views are not overwritten by Composer. If the 4.0.1 release changed front-end assets, your old published copies will mask the fix. Re-publish with --force in a branch and diff the changes.

Config file drift. Published config files do not receive new keys automatically. Compare the package's config/<package>.php against your published copy after upgrading; missing keys often fall back silently to defaults rather than erroring.

Debugging blank tools or cards. Check the browser console first, then storage/logs/laravel.log. Blank Nova tools are usually one of: assets not registered, the tool not in tools(), or a JS exception from a mismatched Nova version. php artisan route:list | grep nova confirms whether the tool's routes registered.

Extension points to prefer. Extend the package's Field/Tool classes rather than editing published views, so upgrades remain clean. Put overrides in your own app/Nova namespace and register them explicitly.

Nova licensing. Nova itself is a commercial package; CI and fresh environments need valid Nova credentials. Package tests that boot Nova screens will fail without them, so keep Nova-dependent tests in a suite you can gate.

Pin the major version. Because 4.x tracks Nova 4, use ^4.0 in composer.json and review changelogs before minor bumps; Nova-adjacent packages occasionally bump their Nova compatibility requirement within a minor release.