Nova Range Input Filter Laravel Package

Getting Started

Version 2.0 is a Nova 5 compatibility release. Treat it as a platform upgrade, not a drop-in patch. Start by confirming the host app is already on Laravel Nova 5 and a supported Laravel/PHP version.

1. Read the package composer.json, README, changelog, and any UPGRADE.md before changing dependencies.
2. Upgrade Nova in the host application first, then require the package’s 2.x line.
3. Publish any config, migrations, views, or assets required by the package.
4. Register the package’s Nova tool/card/field/resource exactly as documented for Nova 5.
5. Run migrations, clear caches, rebuild Nova assets, and smoke-test a real resource screen.

Look first at:

• composer.json for Nova/Laravel/PHP constraints.
• The package service provider for registration and publish tags.
• config/ and resources/js/ for publishable config and frontend assets.
• Existing app code that references the package’s Nova field, tool, card, action, filter, or lens classes.

First practical use case: open a Nova resource that uses the package, verify index/detail/form rendering, then create and update a record to confirm authorization, validation, and persistence still work under Nova 5.

Implementation Patterns

• Upgrade in this order: host Laravel app → Nova 5 → this package ^2.0 → application-specific Nova customizations.
• Pin the major version explicitly. Do not allow mixed Nova 4 and Nova 5 package constraints in the same lockfile.
• Keep package-specific Nova registration isolated in NovaServiceProvider or a dedicated service provider so the upgrade diff is easy to review.
• If the package provides fields or cards, test them in all Nova contexts: index, detail, create, update, inline create, and related-resource modals.
• If the package provides tools or cards, verify menu registration, authorization callbacks, route access, and dashboard/metric rendering.
• If the package provides actions, filters, or lenses, test them against real queries and policies; Nova major upgrades often expose assumptions in request payloads, authorization, and serialization.
• Use a staging environment with representative data. Nova upgrades can pass a fresh install but fail on legacy resources, custom tools, or cached assets.
• Add a CI job or local check that installs the app with Nova 5 and the package 2.x only. This catches accidental downgrades and transitive dependency conflicts early.
• Prefer package extension points over vendor edits: publish config, override views, register custom fields/components, and use service-provider bindings.
• After deployment, rebuild frontend assets and clear cached config, routes, views, and Nova assets.

Gotchas and Tips

• The release note is sparse: “upgrade nova V5.” Inspect the actual diff and composer constraints before assuming the upgrade is limited to a version bump.
• Expect a breaking change boundary at 2.0. Nova 4 applications should stay on the previous major line unless the package explicitly supports both.
• Composer conflicts are the first likely failure. Use composer why-not package/name 2.0 and composer update --with-all-dependencies to diagnose.
• Check whether the package requires a newer Laravel/PHP version indirectly through Nova 5. Do not upgrade Nova alone if the app’s PHP or Laravel version is unsupported.
• Rebuild Nova assets after upgrading. Stale compiled assets can make the package appear broken even when PHP-side registration is correct.
• Clear caches aggressively: php artisan optimize:clear, config cache, route cache, view cache, and any Nova asset publishing/cache steps.
• Test authorization explicitly. Nova 5 behavior around tools, cards, actions, and resource visibility may differ from Nova 4.
• Watch for frontend console errors in Nova. If a custom field/card/tool renders blank, check browser console, network requests, and published asset paths before changing PHP code.
• If migrations or config were published under the old version, compare them with the new defaults. Republish only after backing up local customizations.
• Use Laravel logs, Nova route listings, and browser dev tools together when debugging. A 403 is usually authorization; a blank component is often assets or JavaScript; a 500 is usually dependency/config/migration related.
• Keep a rollback plan: lockfile, database backup, published assets, and config. Major Nova upgrades are safer when the package upgrade can be reverted independently.