Nova Permission Tool Laravel Package

Getting Started

• Confirm your app meets v2.0.0 requirements: Laravel 5.8+ and PHP 7.2+. Laravel 6 is explicitly supported.
• Install with a v2 constraint so you do not accidentally resolve v1 on older projects: composer require vendor/package:^2.0.
• Check for auto-discovery in config/app.php / composer.json; if the package is not auto-discovered, register its service provider and alias manually.
• Publish any package config/assets if the package documents them, then set environment-specific values in .env.
• First use case: exercise the package’s primary feature in a local route, command, or test before wiring it into production code.

Implementation Patterns

• Pin ^2.0 in composer.json and update lock files deliberately; v2 is a compatibility break from v1.
• Add a CI matrix covering PHP 7.2, 7.3, 7.4 and Laravel 5.8 / 6.x to match the supported range.
• For upgrades from v1: bump the constraint, run composer update vendor/package, clear cached config/routes/views, and re-publish config if the package ships new defaults.
• Prefer dependency injection or the package facade over direct static calls so tests can swap implementations.
• Keep package configuration in config/ and environment overrides in .env; avoid editing vendor files.
• If the package exposes events, listeners, or drivers, integrate through Laravel’s service container and event system rather than hard-coding calls.

Gotchas and Tips

• Breaking change: v2 drops Laravel 5.7 and older. Projects on L5.7 or earlier must stay on v1 until upgraded.
• PHP 7.2 minimum: do not introduce PHP 7.3/7.4-only syntax in code shared with the package’s supported range.
• Laravel 6 support may depend on upstream constraints; run composer why-not vendor/package 2.0.0 if resolution fails.
• After upgrading, clear caches: php artisan config:clear, route:clear, view:clear, and composer dump-autoload.
• If manual provider registration is required, forgetting to update it after v2 can cause “class not found” or missing binding errors.
• Use composer show vendor/package to confirm the resolved version and check transitive dependency constraints.
• Extension points typically include published config, custom drivers, and package events; prefer these over subclassing vendor internals.