Nova Scroll Buttons Laravel Package

Getting Started

1. Confirm your stack lines up. v1.0.4 adds Laravel Nova 13 support. Before upgrading, check that your application’s Laravel and Nova versions are compatible with Nova 13, and that the package’s composer.json constraint now allows it (typically "laravel/nova": "^13.0").
2. Install or upgrade. Run composer require <vendor>/<package> (or composer update <vendor>/<package> if already installed). Because Nova is a paid, private package, make sure your Composer auth for nova.laravel.com is configured in CI and locally.
3. Publish package assets. Run php artisan vendor:publish --provider="<Vendor>\\<Package>\\<Package>ServiceProvider" to publish config, migrations, and any Nova assets. Then run php artisan migrate if migrations are provided.
4. Register the Nova integration. In app/Providers/NovaServiceProvider.php, add the package’s tool, card, field, or dashboard to the appropriate method (tools(), cards(), dashboards(), or fields()), following the README’s registration snippet.
5. First use case. Open the Nova dashboard and verify the package’s tool/card/field appears and can read from your configured data source. A good smoke test is to load the Nova index, open the package’s UI, and perform one read and one write operation.

Where to look first:

• README.md for registration and configuration snippets.
• The package service provider for bindings, publish tags, and Nova bootstrapping.
• config/<package>.php for environment-driven behavior.
• The package’s tests/ directory for expected usage and Nova testing patterns.

Implementation Patterns

• Config-first integration. Keep environment-specific values in config/<package>.php and reference them with env() only inside config files. This keeps php artisan config:cache safe in production.
• Register Nova components explicitly. Tools, cards, fields, and lenses usually need to be registered in NovaServiceProvider. Treat this as the package’s public integration point rather than editing vendor files.
• Use policies and Nova authorization. If the package exposes resources, actions, or tools, gate access through Laravel policies and Nova’s canSee/canRun callbacks. This lets you roll out the package to a subset of users.
• Wrap writes in actions or jobs. If the package triggers external calls or heavy queries from a Nova card/tool, move the work into a queued job or Nova action so the dashboard stays responsive.
• Test against Nova’s helpers. Use Nova::actingAs($user) in feature tests, RefreshDatabase for migrations, and assert the package’s routes/components render. Add a CI job that installs Nova 13 to catch compatibility drift early.
• Pin deliberately. If you support both older Nova and Nova 13, keep a wide constraint and test both. If you only support Nova 13 going forward, tighten the constraint and document the dropped versions.
• Upgrade path. After composer update, run php artisan nova:publish if the package ships Nova assets, clear cached config/routes (php artisan optimize:clear), and re-run your Nova feature tests.

Gotchas and Tips

• Nova 13 is a compatibility change, not necessarily a feature change. v1.0.4 likely only widens the Nova constraint. Check the diff/changelog to confirm whether older Nova versions are still supported before assuming a non-breaking upgrade.
• Private Composer credentials are the usual CI failure. Nova requires authentication; missing COMPOSER_AUTH or ~/.composer/auth.json will look like a package failure rather than a Nova failure.
• Composer constraint conflicts. If your app still uses an older Nova major, v1.0.4 may not install. Read the package’s composer.json before upgrading and use composer why-not to diagnose conflicts.
• Asset caching. Nova tools and cards often ship compiled assets. Run the package’s publish/build step and php artisan nova:publish; stale assets are a common “it works locally but not in production” cause.
• Config cache surprises. Any direct env() call outside config files will return null after config:cache. Move package-related environment reads into the published config file.
• Debugging routes and components. Use php artisan route:list to confirm the package’s Nova routes are registered, and check Nova::version() to verify the runtime Nova version matches what Composer resolved.
• Extension points. Prefer the package’s published config, events, and Nova callbacks over subclassing vendor classes. If you must customize behavior, bind your implementation in a service provider and keep the override in app/, not vendor/.
• Authorization defaults. New Nova tools/cards can be visible to all Nova users by default. Add explicit canSee logic before deploying to production.