Oauth Bundle Laravel Package

Getting Started

Before installing, establish your baseline — this release is fundamentally about a compatibility ceiling, not new functionality:

php -v
composer show | grep -E 'symfony/|laravel/framework'

• On PHP < 7.3 or Symfony < 4.3: this is your terminal version. Require it explicitly with a bounded constraint so a future major doesn't silently break your stack:

  composer require vendor/package:"^1.0"
  

• On PHP 7.3+ / Symfony 4.3+: treat 1.0.0 as a floor, not a target. Install the latest release; you are not the audience for this version's pinning advice.

First use case: publish the package config (php artisan vendor:publish --provider="Vendor\Package\ServiceProvider") and exercise the happy path in a single feature test before wiring it into anything else. If package auto-discovery is enabled, confirm with php artisan about that the provider actually registered — legacy-stack installs are where discovery silently fails due to cached bootstrap/cache/packages.php.

Where to look first: the package's composer.json require block. It tells you exactly which Symfony component versions you're constrained to, which is the real determinant of whether this release fits your application.

Implementation Patterns

Pin your platform, not just your package. The most common failure mode with a version like this is that it installs fine locally (PHP 7.4) and explodes in CI (PHP 7.2) or vice versa. Lock it in composer.json:

"config": {
    "platform": { "php": "7.2.34" }
}

Contain the dependency behind an adapter. Since 1.0.0 marks the end of a support line, isolate it behind a small interface in your app so the eventual upgrade to 2.x is a single-file change:

interface ThingContract { public function handle(array $payload): Result; }

Split your test matrix by constraint. Run one CI job on PHP 7.2 against ^1.0 and another on your current PHP against the newest release. This surfaces upgrade friction continuously instead of in one painful batch.

Treat config as environment-driven. Anything the package reads from config/*.php should be overridable by env var, so staging and production can differ without republishing the config file.

Queue and scheduling integrations are the usual day-to-day surface: wrap package calls in your own job classes rather than dispatching package internals directly — that keeps retry/backoff semantics under your control and survives a major upgrade.

Gotchas and Tips

• This version is a dead end by design. No new features will land on the 1.x line. Plan a migration ticket the moment you adopt it; don't let it sit in composer.json unexamined for a year.
• Constraint bubbling is the top blocker. When composer require fails, composer why-not vendor/package 1.0.0 tells you which package is holding back Symfony far faster than reading the solver output.
• Don't let composer update roam. Commit composer.lock and use composer install in CI. Without the platform pin, a routine update on a different PHP version can resolve a completely different dependency graph.
• Cached config masks upgrades. After changing the package version, run php artisan config:clear && php artisan cache:clear before concluding something is broken — stale bootstrap/cache is the cause more often than the package itself.
• Read the CHANGELOG for the next major before you commit to 1.0.0. The deprecations that will bite you at upgrade time are usually already documented there, and knowing them now shapes which extension points you lean on.
• Extension points to prefer: interfaces and config-driven behavior over subclassing package internals. Subclassing is the first thing to break across a major.
• Debugging tip: when behavior differs between environments, dump the resolved config (config('package.key')) from php artisan tinker in both — it distinguishes a genuine package bug from a publish/env mismatch in one step.