Laravel Scavenger Laravel Package

Product Decisions This Supports

• Platform currency / upgrade planning. v4.0.0 is a major release that supports Laravel 12 and 13 and requires PHP 8.3+. This is the deciding input for "do we adopt, hold, or fork" — anyone still on Laravel 10/11 or PHP 8.1/8.2 cannot take v4, so the roadmap question becomes "when does our app's PHP/Laravel upgrade land," not "should we upgrade this package."
• Build vs. buy for long-running / authenticated background work. The package ships a daemon that authenticates as an Eloquent model, and now defaults that model to App\Models\User. If our near-term roadmap includes any always-on worker that acts on behalf of a user (polling, sync, fetching, monitored jobs), that's the make-or-break plumbing we would otherwise build and maintain ourselves.
• Dependency risk reduction. Goutte is replaced by Symfony HttpBrowser. Goutte has been effectively superseded by Symfony BrowserKit, so this removes an aging dependency from our supply chain — a security/maintenance posture win we can report on, not just an internal refactor.
• Feature scoping for outbound HTTP behavior. guzzle_settings.timeout now governs both the idle timeout and the maximum total request duration. That turns timeouts into a real product constraint: any workflow that legitimately runs long (large downloads, slow upstream APIs, paginated fetches) gets a hard ceiling and will start failing unless we deliberately configure it. This should be a scoped work item, not a config afterthought.
• Credential lifecycle for daemon identities. The fix to double-hashing for models using Laravel's hashed cast is a correctness win but has a migration consequence: any daemon credential stored under the old double-hash behavior may no longer authenticate. Plan for a credential reset/rotation path and a support note before rollout.
• Support and ops readiness. A major bump that changes the HTTP client, the default auth model, and password handling is a support-surface event. Budget for a release note to internal users, an upgrade runbook, and monitoring on daemon auth failures and timeout-induced job failures for the first weeks after rollout.

When to Consider This Package

Adopt when:

• We are on (or committing to) PHP 8.3+ and Laravel 12/13, and that upgrade is already on the roadmap.
• We need a long-running, authenticated worker process rather than per-request execution — i.e., the daemon model is the reason we're here, not incidental.
• Our outbound fetching is straightforward HTTP (HTML, JSON, APIs) and does not require JavaScript execution.
• We use a conventional Eloquent user model, or we're prepared to point the config at our own model.
• We can absorb a breaking upgrade with a planned window, including a credential reset for daemon accounts.

Look elsewhere (or stay on the prior major) when:

• We're pinned below PHP 8.3 or Laravel 12 — v4 is simply unavailable; treat this as a hold, not a rejection.
• We need headless browser rendering, JS-heavy pages, or bot-challenge handling — HttpBrowser is not a headless browser; that's a different tool class (Playwright/Panther-style).
• Our throughput requirement exceeds a single daemon's capacity and we'd need horizontal scaling/queue fan-out the package doesn't provide.
• Our auth model is highly customized in ways that conflict with the "default to App\Models\User" assumption and the hashed cast path — validate before committing.
• We only need occasional scraping; a one-off HTTP client plus a queued job is cheaper than operating a daemon.

Before committing, get answers on: the upgrade/migration path for stored daemon credentials, what the new timeout semantics do to our slowest existing jobs, and whether anything in our code relies on Goutte-specific behavior (redirects, cookies, form handling) that HttpBrowser implements differently.

How to Pitch It (Stakeholders)

For executives: This is a maintenance-and-risk release, not a feature release. It keeps us on supported Laravel and PHP versions, retires a dependency that the ecosystem has moved past, and fixes a security-adjacent bug where daemon passwords were being hashed twice. The cost is a planned upgrade window plus a credential reset for daemon accounts; the risk of staying put is falling off supported framework versions. No new spend, no vendor change.

For engineering: v4.0.0 requires PHP 8.3+ and Laravel 12/13 — confirm our upgrade timeline before scheduling. Three behavior changes to plan around: (1) Symfony HttpBrowser replaces Goutte, so validate redirect/cookie/form semantics and remove Goutte-specific assumptions; (2) guzzle_settings.timeout is now both idle timeout and max request duration, so audit every long-running fetch and set explicit ceilings; (3) the double-hash fix on hashed-cast daemon models means existing daemon credentials likely need rotation — build that into the rollout, don't discover it in production. Also confirm the new App\Models\User default matches our config or override it explicitly. Recommend a staged rollout with monitoring on daemon auth failures and timeout-related job failures.