Php Paginator Laravel Package

Getting Started

• Require the new line explicitly: composer require <vendor>/<package>:"^3.3". This is the only branch that resolves against illuminate/http:^13.0 and illuminate/support:^13.0.
• If your app is still on Laravel/Illuminate 12, stay on ^3.2 — that constraint line remains valid and is the documented fallback in the release notes.
• Confirm the PHP floor before upgrading: ^8.3 is unchanged, and the package is tested against PHP 8.5, so a PHP bump and the Illuminate bump can be done in the same pass without extra risk from this package.
• First place to look after install is the package's service provider registration and any publishable config (php artisan vendor:publish). Laravel package auto-discovery means there is usually no manual config/app.php wiring, but verify the provider is listed if discovery is disabled in your app.
• First use case: make a single call through the package's HTTP layer (facade, injected client, or manager class) in a tinker session, assert the response shape, then wrap it in a feature test with Http::fake() before touching application code.

Implementation Patterns

• Dual-line CI matrix. If you maintain downstream packages or a monorepo, add a job per Illuminate major: one resolving illuminate/*:^12.0 against <package>:^3.2, one resolving ^13.0 against <package>:^3.3. Composer will not let you test a single lockfile against both.
• Version-constrained dependency declaration. When depending on this package from another package, mirror the constraint rather than hard-pinning a major: "<vendor>/<package>": "^3.2" is the safest declaration — it allows 3.3 on Illuminate 13 and still resolves 3.2 on Illuminate 12, letting the consumer's framework version pick the branch.
• Wrap the client, don't scatter it. Because the package builds on illuminate/http, bind its client into the container once (a singleton in a service provider or a thin app-level wrapper) and inject that. It keeps the upgrade surface to one file when the next Illuminate major lands.
• Fake at the HTTP boundary in tests. Use Http::fake() / Http::assertSent() around the package rather than mocking the package's own classes; that's the seam that survives minor and patch releases.
• Staged upgrade order in a real app. Bump PHP to 8.3+ first, then Laravel/Illuminate to 13, then this package to ^3.3. Doing the package first leaves Composer unable to resolve the transitive illuminate/* constraints.
• Config-driven behavior. Prefer published config values over constructor arguments for anything environment-dependent (base URLs, timeouts, retry counts) so staging and production differ by env, not by code branch.

Gotchas and Tips

• The 3.3.0 change is a constraint bump, not an API change. The release notes list only Changed — no Added, Deprecated, or Removed. Treat 3.2 → 3.3 as a drop-in on Illuminate 13, but still run your test suite because Illuminate 13 itself may change behavior underneath.
• ^13.0 is a hard floor in the package's own require. If your composer.json pins illuminate/support to ^12.0, composer update will silently keep you on 3.2 — or fail loudly if you asked for ^3.3. Check composer why-not <vendor>/<package> 3.3.0 when the upgrade "doesn't take."
• Don't mix branches in a lockfile. Two packages in the same app disagreeing on Illuminate major is unresolvable; the conflict message will name illuminate/http or illuminate/support, not the package that actually forced it. composer depends illuminate/support finds the culprit quickly.
• PHP 8.5 compatibility is tested, not required. The floor is ^8.3. Running 8.5 is supported by the package's CI, but your other dependencies may not be — validate the whole graph, not just this package.
• Lumen / non-standard skeletons. If you're not on a stock Laravel skeleton, auto-discovery won't fire; register the provider and any facade alias manually, and confirm illuminate/http is actually present in the container (Lumen ships a slimmer default set).
• Extension points. The stable seams are the published config file, the container binding for the client, and (if present) any manager/driver interface. Prefer extending via a decorator bound over the package's binding rather than subclassing internals — internals are the part most likely to shift at the next Illuminate major.
• Debugging requests. Since the underlying transport is illuminate/http, Http::preventStrayRequests() plus a global Http::globalRequestMiddleware() (or the package's own logging hook, if configured) will show you exactly what it sends without patching vendor code.
• Pin the fallback deliberately. If you must ship on Illuminate 12 for a while, put "<vendor>/<package>": "~3.2.0" rather than ^3.2 in apps that will later upgrade — it prevents an accidental 3.3 pull-in during an unrelated composer update once someone else bumps the framework.
• Watch for a 3.2.x security backport. The notes only say "stay on ^3.2"; confirm the 3.2 line is still receiving patches before committing to it long-term, and track the package's changelog for a 3.2.1+ release.