Laravel Zxcvbn Laravel Package

Getting Started

• Install with Composer and let the package's own constraint drive the Laravel version. As of 1.6.0 the package supports every Laravel release after 5.4, so the same composer require line works across the 5.x, 6.x, 7.x, 8.x, 9.x, 10.x, 11.x, and 12.x lines — you no longer need a separate fork or a pinned major for older apps.
• Look first at the package's composer.json. The require block tells you the PHP floor (this matters more than the Laravel floor: 5.4 runs on PHP 5.6.4+, but the package may need 7.x), and the extra.laravel block tells you which service providers and facades are auto-registered.
• On Laravel 5.5+ auto-discovery handles provider and facade registration. On 5.4 you must add the provider to config/app.php['providers'] and the facade to ['aliases'] by hand; there is no package:discover step to rely on.
• Publish config and any assets before first use (php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider") so the defaults are visible and editable, then run migrations if the package ships them.
• First use case: integrate the package behind a single controller action or queued job, confirm it behaves on your exact Laravel version, then widen the footprint. Do not wire it globally until one path is verified.

Implementation Patterns

• Resolve the package from the container (constructor injection or a type-hinted contract) rather than reaching for the facade. This keeps it swappable in tests and is the pattern most likely to survive future major releases.
• Treat configuration as the integration seam. Read package settings from config/... and override per environment; avoid editing vendor defaults so upgrades stay clean.
• If you support more than one Laravel major in a shared codebase, gate newer framework APIs behind version_compare(app()->version(), '8.0', '>=') checks or small adapter classes. The package supporting 5.4+ does not mean your own application code should assume 5.4-era APIs.
• Bind a fake or stub in the test suite ($this->instance(...) or $this->swap(...)) so feature tests do not depend on live external calls. Package facades are the usual place tests leak.
• Keep package usage in a thin service or action class. When the package eventually changes its API, the blast radius is one class rather than every controller.
• For queued or scheduled work, run the integration inside a job and test it with Bus::fake() / Queue::fake() to confirm dispatch without executing the package during the test run.
• Verify the version matrix in CI if the package is load-bearing: at minimum the lowest Laravel you claim to support (5.4) and the current one. Composer's --prefer-lowest is the cheap way to catch a broken floor.

Gotchas and Tips

• 1.6.0 is a compatibility-widening release only: no breaking changes, no new public API, no deprecations. The meaningful action item is to re-check your composer.json constraint and confirm your CI matrix actually exercises the old and new ends of the supported range.
• Laravel 5.4 is the odd one out. Auto-discovery does not exist there, so a package that "works on 5.4" still needs manual provider and alias registration. Reproduce that path explicitly if you claim 5.4 support.
• Config caching bites: after php artisan config:cache, package config changes are ignored until you clear it. Same for route:cache if the package registers routes.
• When auto-discovery appears not to fire, check bootstrap/cache/packages.php — it is the generated manifest of what Laravel believes is registered — and re-run php artisan package:discover after editing composer.json.
• PHP version, not Laravel version, is the more common install failure on 5.4-era apps. Read the Composer error rather than assuming the Laravel constraint is the blocker.
• Use composer why-not vendor/package 1.6.0 to see exactly which dependency is holding you back when the upgrade will not resolve.
• Extension points are usually the published config plus container bindings; prefer those over editing vendor files so the next patch release applies cleanly.
• Debugging tip: when behaviour differs between Laravel versions, log app()->version() alongside the failure. Most cross-version issues are framework API drift (container resolution, model events, HTTP client), not package-specific bugs.