Laravel Oauth2 Login Laravel Package

Getting Started

• Confirm your framework matrix before anything else. v1.13.0 supports Laravel 9 (LTS) through 10 only. Anything on Laravel 8 or earlier must either stay pinned to a pre-1.13 release or be upgraded first — the package will not resolve. Check with composer why-not vendor/package ^1.13 if the constraint fails.
• Install against a supported stack:

  composer require vendor/package:^1.13
  

  Laravel 10 implies PHP 8.1+; Laravel 9 supports PHP 8.0+. Verify php -v matches before chasing resolution errors.
• Look first at the service provider and the published config. Run the package's publish command (php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider") and read the resulting config/<package>.php top to bottom. In most Laravel packages of this shape, the config file is the real API surface — defaults, driver selection, and connection settings all live there.
• First use case: wire up the smallest end-to-end path in a throwaway route or php artisan tinker session — resolve the package's main class from the container, call one method, and confirm it returns without touching config. That tells you whether the auto-discovery and default bindings work on your Laravel version before you invest in real integration.
• Read the CHANGELOG entries between your current version and 1.13.0, not just the 1.13.0 notes. "Removed some older versions" means the package's own backward-compatibility shims may have been dropped alongside the framework support matrix.

Implementation Patterns

• Inject, don't app()-resolve, in application code. Constructor-inject the package's contracts into your services and controllers. This keeps your code testable and lets you swap the package's binding for a fake later. Reserve app() / facades for one-off scripts and Artisan commands.
• Publish-and-commit the config. Treat config/<package>.php as application code: commit a single version and drive environment differences through env() calls inside it, not by keeping divergent config files per environment. This matters more post-upgrade, since Laravel 9→10 changed how some env() fallbacks behave under config:cache.
• Wrap the package behind your own thin adapter. A small App\Services\... class that owns all calls into the package pays for itself at every major version bump. When 2.x drops, you edit one class instead of grepping the codebase. This is especially valuable given the package just demonstrated it will prune old framework support aggressively.
• Upgrade workflow for the 1.13.0 move:
  1. Bump the package constraint in composer.json.
  2. Bump laravel/framework to ^9.0|^10.0 if you haven't already.
  3. composer update vendor/package --with-dependencies and read every conflict message — a dropped older version usually surfaces as a transitive dependency clash, not a direct one.
  4. Re-publish the config and diff it against yours; new keys appear without migration notes.
  5. Clear caches: php artisan config:clear && php artisan cache:clear && composer dump-autoload.
• Queue and event integration: if the package dispatches jobs or events, put them on a named queue in config rather than relying on the default. On Laravel 10 the Bus::dispatchAfterResponse and job-batching semantics are worth re-testing after the bump.
• Testing pattern: bind a fake into the container in setUp() or use the package's provided test helpers if they exist. With RefreshDatabase plus a faked binding you get fast, deterministic tests that don't care which Laravel minor you're on.

Gotchas and Tips

• The big one: dropped older framework versions is a breaking change in practice. Semver-wise this is a minor release; operationally it is not. Anyone on Laravel 8 or below gets a hard resolver failure on composer update. Pin explicitly ("vendor/package": "~1.12") if you cannot upgrade the framework yet, and put that pin in writing so it isn't silently lifted by a composer update on a colleague's machine.
• composer why-not is your first debugging tool, not the package's issue tracker. Nine times out of ten a v1.13.0 install failure is a PHP version floor or a transitive package still requiring an older framework.
• Config cache traps. After upgrading, php artisan config:cache will bake in whatever env() values exist at build time. If behaviour differs between php artisan serve and your deployed container, that's the cause — clear and rebuild the cache as part of deploy, never commit bootstrap/cache/config.php.
• Laravel 10 removed doctrine/dbal as a core dependency. If the package (or your own code around it) relied on ->change() migrations or ->getDoctrineColumn(), add doctrine/dbal explicitly or rewrite those migrations. This bites during the upgrade window, not at install time.
• Auto-discovery can be stale. If the package's provider doesn't register after an upgrade, check bootstrap/cache/packages.php and run php artisan package:discover. A stale manifest is the usual culprit, not a broken release.
• Extension points to look for before forking anything: container bindings for the package's interfaces (override in your own AppServiceProvider::register()), custom driver registration in the config, and any macroable classes. Most "the package doesn't support X" problems are solved by rebinding an interface rather than patching vendor code.
• Watch the next release. A maintainer who drops old framework support in a minor version is signalling a fast-moving support policy. Pin to ^1.13 rather than *, and read changelogs before composer update in CI — consider composer outdated --direct in your pipeline to surface these bumps deliberately.