Laravel Pwned Passwords Laravel Package

Product Decisions This Supports

• Framework upgrade planning (highest-value use): Release 3.4.0 adds PHP 8 support, which converts a previously blocking dependency into a viable one for any roadmap item gated on PHP 8 / Laravel 8–10 modernization. This is the decision this release most directly unlocks.
• Build vs. buy: A package that keeps pace with current PHP runtimes is a defensible "buy/borrow" choice over in-house reimplementation — the maintenance burden you are avoiding (runtime compatibility, security patching) is exactly the burden the vendor just demonstrated they carry.
• Deprecation and lifecycle risk: PHP 8 support signals the maintainer intends to stay on supported runtimes. Use it as evidence for the longevity assumption in your dependency register; absence of it would be an argument for replacement.
• Security posture: Running on PHP 7.x past end-of-life is a compliance and audit exposure. This release removes one blocker to getting off EOL runtimes, which is a security/risk decision as much as an engineering one.
• Scope and sequencing: Supports a sequencing call — schedule the package bump before the runtime upgrade, and confirm the package works under PHP 8 in staging rather than assuming it.
• Not a feature decision: A runtime-support release adds no user-facing capability. Do not let it consume roadmap capacity or be positioned as a product improvement.

When to Consider This Package

Adopt or retain when:

• Your stack is Laravel/PHP and you are planning or mid-flight on a PHP 8 (or later) upgrade.
• The package is already a dependency — 3.4.0 is a low-risk, high-leverage version to bump to before a runtime change.
• You are evaluating a new dependency and the alternative candidates do not yet declare PHP 8 support; this one does, which reduces future migration work.
• You need a maintained dependency to satisfy a security or EOL-remediation commitment.

Look elsewhere or hold when:

• You are still on PHP 7.x with no near-term upgrade plan — the release offers you nothing today, and adopting now only front-loads a compatibility test. Bump when the runtime moves.
• The release notes are the only signal you have. "PHP 8 support" is a claim, not proof of quality; check test matrix coverage, open issue volume, release cadence, and whether other dependencies in the same chain also support PHP 8.
• The package is peripheral and the PHP 8 bump forces cascading upgrades of transitive dependencies — in that case the cost belongs to the platform upgrade, not to this package's evaluation, and should be scoped there.
• You need functionality this package does not provide. Runtime support is table stakes, never a differentiator on its own.

Pre-adoption gates: verify CI actually runs against PHP 8, confirm no breaking API changes hide behind the minor version number (compare the changelog between 3.3.x and 3.4.0), and identify a fallback if the upgrade surfaces incompatibilities.

How to Pitch It (Stakeholders)

To executives: A dependency we rely on has added support for PHP 8, the current supported runtime. This is a maintenance release, not a new capability — no customer-facing change and no incremental cost. Its value is risk reduction: it clears one of the blockers on our runtime-upgrade path, which is how we get off an end-of-life PHP version and close a standing security and audit finding. Recommendation is to proceed with the upgrade as part of the existing platform-modernization workstream; it is not a standalone initiative and does not change the roadmap.

To engineering: Version 3.4.0 adds PHP 8 support and nothing else. Sequenced before the runtime upgrade, treat it as a compatibility enabler, not a feature. Before merging: read the full 3.3.x→3.4.0 diff to rule out behavioral changes, confirm the package's CI matrix covers PHP 8 rather than only asserting it, and run the suite under PHP 8 in staging with attention to transitive dependencies that may not yet be ready. Note that runtime modernization — not this bump — is the work item that carries the schedule and testing cost, and scope it there.

To security/compliance: This release removes a dependency-level obstacle to retiring PHP 7.x. It does not itself remediate the EOL finding; the finding closes when the runtime is upgraded in production. Treat 3.4.0 as a prerequisite milestone with evidence — version bumped, tests green under PHP 8 — rather than as closure.