Request Token Bundle Laravel Package

Getting Started

v1.2.0 is a platform-floor release: PHP >= 8.2 and Symfony >= 7.4 are now hard requirements. There are no new features to learn, so "getting started" is really "confirming you're allowed to install it."

1. Check your actual stack before touching composer.json. In a Laravel app the Symfony constraint is dictated by the framework, not by you:

   php -v
   composer show laravel/framework | grep -i versions
   composer why symfony/console
   

   Symfony 7.4 lands with the newest Laravel majors. If you're still on a Laravel line that pins Symfony 6.x or 7.0–7.2, this release is simply not installable for you — that is the first thing to establish, and it usually ends the evaluation in under a minute.

2. Read the package's own composer.json (vendor/<vendor>/<package>/composer.json) rather than trusting the release note. Look at require for the exact php and symfony/* constraints, and at require-dev/suggest to see what the maintainers actually test against. The release note is a summary; the manifest is the contract.

3. Install in a branch, not on main:

   composer require <vendor>/<package>:"^1.2" --with-all-dependencies
   

   --with-all-dependencies matters here — a PHP/Symfony floor bump frequently drags shared transitive dependencies forward, and without -W Composer will happily leave you on v1.1.x and report success.

4. First use case: whatever the package's primary entry point is (a facade, a manager, a console command), exercise it once in php artisan tinker before wiring it into a controller or job. On a version-bump release the goal of the first run is purely "does it boot under 8.2," not "does my feature work."

5. If the package publishes assets, publish them into the app so your config is explicit and diffable in review:

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

Implementation Patterns

Treat the upgrade as a coordinated platform move, not a package bump. PHP 8.2 and Symfony 7.4 are coupled: you generally cannot satisfy the Symfony side without also being on a recent Laravel major. Sequence it as one PR — PHP version in CI, framework upgrade, then this package — rather than three PRs where the middle one is red for a week.

Pin the constraint and let the lockfile do the talking:

"require": {
    "<vendor>/<package>": "^1.2"
}

Then verify what actually resolved:

composer show <vendor>/<package>     # confirm 1.2.x, not 1.1.x

Run a CI matrix over the supported floor and ceiling. For a package whose only change is platform support, the valuable signal is: PHP 8.2 (the new minimum) and your production PHP version, crossed with the lowest Laravel you claim to support. Testing only on latest-everything is how floor bumps break silently.

Resolve through the container, don't new up internals. If you've been instantiating the package's classes directly, this is the moment to move behind an interface binding in a service provider. Platform-bump releases are exactly when internal constructors shift signatures, and container resolution localizes the blast radius to one binding.

Gate the upgrade behind your own abstraction if rollout is staged. If some apps run 8.1 and some run 8.2, keep the package behind a small internal adapter with two implementations, so the version constraint lives in one place instead of leaking into feature code.

Fold deprecation handling into the same PR. Add to phpunit.xml:

<ini name="error_reporting" value="-1"/>

so PHP 8.2 deprecations surface as failures during the upgrade rather than as production log noise three weeks later.

Gotchas and Tips

• Composer failing "silently." The classic failure mode: you run composer require without -W, Composer reports success, and you're still on v1.1.x because the new floor is unsatisfiable. Always follow up with composer show and, when a constraint blocks you, composer why-not <vendor>/<package> 1.2.0 — that command names the exact conflicting package and version, which saves a lot of guessing.

• The floor bump is a breaking change for downstream consumers. Anyone on PHP 8.0/8.1 or an older Laravel needs a major-version-style migration note even though the tag says 1.2.0. If the package doesn't publish an UPGRADING.md, consider pinning ^1.1 in older apps and documenting why in your own changelog.

• PHP 8.2 deprecations that bite quietly: dynamic property creation (now deprecated — add #[AllowDynamicProperties] or declare the properties), ${var} string interpolation, and utf8_encode/utf8_decode. These surface as notices, so a permissive error_reporting in production hides them until a future PHP version escalates them to errors.

• Symfony 7.4 signature changes. If you extend package classes or implement its interfaces, run composer update and then check for "Declaration must be compatible" fatals. Subclassing is the top source of upgrade breakage; prefer decorating or binding over extending.

• Config cache staleness. After publishing or editing package config, php artisan config:clear (and cache:clear in some setups). A stale cached config reading a key that no longer exists produces confusing null behaviour that looks like a package bug.

• Extension points, in order of preference: (1) publish and edit config, (2) bind your own implementation to the package's interface in a service provider, (3) decorate the service, (4) subclass — and only if the maintainers document it as supported. If the only way to change behaviour is (4), that's worth raising upstream rather than absorbing.

• Debugging checklist for "it won't install": php -v → composer show laravel/framework → composer why-not → composer diagnose. In that order. Ninety percent of the time the answer is at step one or two, and the release note's "PHP 8.2 minimum" is the whole explanation.