Categorizable Laravel Package

Getting Started

• Confirm the upgrade path. Release 1.3.2 adds Laravel 6 support. Check the package’s composer.json for a laravel/framework constraint such as ^6.0, then install with:

  composer require vendor/package:^1.3
  

  If you are already on 1.3.x, a patch-level bump should be low risk, but run your test suite after updating.
• Register the provider if needed. Laravel 6 supports package auto-discovery. If the package does not advertise it, add its service provider to config/app.php.
• Publish and review assets. Publish config, migrations, views, or translations before using the package:

  php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"
  

  Review published migrations with --pretend before running them in shared environments.
• First use case. Resolve the package’s main service from the container or use its documented facade/helper inside a controller, command, or job. A quick smoke test in php artisan tinker is usually the fastest way to confirm the container binding and configuration are correct.
• Where to look first. Start with the README’s Laravel 6 notes, the service provider, the published config file, and the package changelog. Since 1.3.2 only advertises Laravel 6 support, do not expect new public API surface; focus on compatibility and dependency constraints.

Implementation Patterns

• Inject, don’t resolve ad hoc. Constructor-inject the package’s services into controllers, jobs, and artisan commands. This keeps your code testable and makes it easy to swap or decorate the package later.
• Keep configuration in config files. Move environment-specific values into config/ and reference them through config(). Avoid calling the package with hard-coded credentials or endpoints spread across the codebase.
• Wrap third-party calls in your own service layer. Even a thin wrapper around the package makes it easier to add logging, retries, feature flags, and fallback behaviour without touching vendor code.
• Use package events and extension points. If the package dispatches events or exposes macros, drivers, or bindings, prefer those over subclassing internals. Listen for events to decouple side effects such as notifications or audit logging.
• Test against Laravel 6 explicitly. Add a CI matrix row for Laravel 6 and the PHP versions you support. For application tests, use RefreshDatabase where migrations are involved. For package-level integration tests, orchestra/testbench is the standard choice.
• Upgrade workflow. Bump the constraint, run composer update vendor/package --with-dependencies, clear caches (php artisan config:clear, php artisan package:discover), then run the full test suite. In production, deploy behind a staging check and monitor deprecation logs.
• Cache-aware integration. If the package registers routes, config, or bindings, verify it works with php artisan config:cache and php artisan route:cache. Laravel 6 production deployments commonly enable these, and packages that resolve services too early can break.

Gotchas and Tips

• Laravel 6 is old but LTS. It requires PHP >=7.2. Confirm your runtime, CI images, and deployment targets match. If your application is on Laravel 7 or newer, 1.3.2 may not be the right version—check the package’s constraint matrix before assuming forward compatibility.
• Helper removals in Laravel 6. Laravel 6 removed several legacy helpers such as str_slug and array_add. If the package previously targeted Laravel 5.x, 1.3.2 should have addressed internal usage, but watch for deprecation notices from your own code or transitive dependencies.
• Auth scaffolding is separate. Laravel 6 moved auth scaffolding to laravel/ui. Do not expect this package to provide UI scaffolding unless its documentation explicitly says so.
• Auto-discovery cache. After installing or updating, run php artisan package:discover. If the package’s provider is not discovered, confirm the extra.laravel.providers entry in its composer.json.
• Dependency conflicts. Use composer why-not vendor/package 1.3.2 to diagnose version conflicts, and composer show vendor/package to confirm the installed version. Patch releases can still conflict with pinned transitive dependencies.
• Debugging. Enable the package’s debug flag if it has one, check Laravel’s log for container or config resolution errors, and use php artisan tinker to verify bindings in isolation. If the package makes HTTP calls, inspect the client configuration and timeouts.
• Pin and lock. Use a constraint such as ^1.3 in composer.json and commit composer.lock. Treat future minor releases as potentially additive and test them in staging before production.
• Extension points over vendor edits. Prefer publishing config, binding interfaces, decorating services, or listening to events. Never edit files under vendor/; those changes will be lost on the next composer update.