Nova Actions Left Laravel Package

Getting Started

This release (v0.3.0) is described only as "Update for nova 3" — a Nova 3 compatibility bump. Everything below is based on that single fact plus the package's pre-1.0 version number; verify specifics against the tag diff before adopting.

What the release tells you

• The package is a Laravel Nova extension (tool, card, field, or resource tool) that previously targeted Nova 1.x/2.x and now targets Nova 3.x.
• Nova 3 means Laravel 6/7, PHP 7.2+, and the nova.mix.js / ToolServiceProvider era of asset registration. It does not imply Nova 4 or 5 support — if your app is on Nova 4+, assume this package will not work until you confirm otherwise.
• Version 0.3.0 is pre-1.0, so a minor bump may still contain breaking changes by semver convention.

Minimal steps

1. Read composer.json in the tag. Look only at two things: the nova constraint (^3.0?) and the illuminate/* constraints. Those tell you whether you can install it at all.
2. Diff v0.2.x → v0.3.0. Given the terse note, expect the change set to be small: a constraint bump, a NovaServiceProvider/Tool registration tweak, and possibly a rebuilt compiled asset. Knowing exactly what moved is cheaper than reading the README.
3. Install alongside your Nova install (composer require vendor/package:^0.3). Because Nova itself is not on Packagist, this only resolves if your project already has a path/vcs repository or a Nova credentials/satis setup configured — if composer require hangs on laravel/nova, fix that first.
4. Register in app/Providers/NovaServiceProvider.php — tools() for a tool, cards() for a dashboard card, or a field's make() in a resource. The service provider should be auto-discovered; confirm it's listed under extra.laravel.providers.
5. If the package ships publishable config/views/migrations, run php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" and read the published config before touching anything else.

First use case: register the tool, hit /nova, and confirm the nav item renders. If it renders but 404s or 500s, the asset manifest is the usual culprit (see Gotchas).

Implementation Patterns

Registration belongs in NovaServiceProvider, not AppServiceProvider. Nova packages assume their boot runs after Nova's own; putting Nova::tools() or a card registration in the wrong provider produces silent non-appearance rather than an error.

Tool vs. card vs. field — decide early. If the package exposes all three, you don't need all three. A tool gives you a full Vue page in the sidebar (good for dashboards/reports); a card is a widget on the Nova dashboard (good for a single metric); a field embeds into resource forms (good for custom input types). Registering a tool you only use as a field adds an unused sidebar entry and asset weight.

Assets and build pipeline. Nova 3 packages register compiled assets via Nova::script() / Nova::style() in the tool's boot(), with sources built through nova.mix.js. If you are forking or patching, you must rebuild with the Nova 3 Mix helper, not a plain Laravel Mix config — the output paths and vendor chunking differ, and mismatched manifests are the #1 cause of a blank Nova page.

Authorization. Most Nova 3 tools expose canSee() / authorize() callbacks or rely on Nova gates. Wire these to your existing policies rather than relying on the default true, especially if the tool surfaces user data. Check whether the v0.3.0 diff touched authorization — a Nova-3 port is exactly the kind of change where a canSee signature quietly shifts.

Pin the version. With 0.x and a thin changelog, use "vendor/package": "0.3.*" rather than ^0.3 if you value reproducibility across Nova-3-era projects. You are the release notes.

Treat the Nova 3 port as an integration test, not a feature. Before building on it, write one Nova feature test (or a Dusk assertion) that loads the tool route as an authenticated user. It will catch the class of failures this bump is most likely to introduce: route registration, asset manifest, and provider boot order.

Gotchas and Tips

Nova 3 is end-of-life. It targets Laravel 6/7 and PHP 7.2–7.4 (8.0 in later 3.x). If your app is on Laravel 9+ or Nova 4/5, this release is not for you — Nova 4 moved to ToolServiceProvider with boot()/booting(), Nova::script() semantics changed, and nova.mix.js was replaced. There is no forward-compatibility promise here.

The release note is the entire changelog. "Update for nova 3" tells you the target, not the blast radius. Diff the tag; specifically check for renamed namespaces, changed service provider base classes, and any removed public methods. On a 0.3.0, an unannounced breaking change is entirely plausible.

composer require failing on laravel/nova is almost never this package's fault. Nova requires a private repository or path repository. Verify your existing Nova install resolves before blaming the package constraint.

Blank page / unstyled tool after upgrade. Compiled assets from the Nova 2 build won't load under Nova 3. Confirm dist/js/tool.js and dist/css/tool.css exist in the tag and that mix-manifest.json (if used) matches the paths in Nova::script(). Re-publish assets (php artisan vendor:publish --tag=nova-assets --force where applicable) and clear bootstrap/cache.

Config caching masks registration changes. After any provider or tool registration edit, run php artisan config:clear && php artisan route:clear && php artisan view:clear. Nova caches aggressively and will happily serve the pre-upgrade route table.

Extension points worth knowing before you fork: the tool's boot() (asset registration), canSee()/authorize() (visibility), the cards()/tools() arrays in NovaServiceProvider, and any published config file. Prefer overriding via config and published views over editing vendor/ — a 0.x package will move under you.

Debugging visibility problems: check Nova::availableTools(request()) in tinker (or a quick route dump) to see whether the tool registered but was filtered by authorization, versus never registering at all. That single check separates 90% of "it's not showing up" reports.