Drift Laravel Package

Product Decisions This Supports

• Test framework standardization (Pest vs. PHPUnit): Drift is a one-shot PHPUnit→Pest codemod, so it supports a roadmap decision rather than a feature decision. Its only legitimate use is answering "how expensive is the migration?" — it does not answer "should we migrate?" That call must be made on team preference, hiring, and documentation grounds, not on tooling.
• Build vs. buy vs. borrow for internal migrations: Archived, last release 2020-09-11, zero dependents, 29 stars. That combination is a clear "do not adopt as a dependency" input and reframes the work as a short internal spike or reference implementation rather than a supported tooling bet.
• Developer-experience funding priority: The maintenance signals say no to this package specifically, which redirects budget toward Pest's first-party migration tooling, Rector-based codemods, documentation, or pairing — all of which are maintained and therefore cheaper over a full migration lifecycle.
• Dependency and technical-debt governance: Supports a standing policy to reject archived tooling even in dev-only/CI contexts, because unmaintained packages create Composer resolution friction, SCA scanner noise (Dependabot, Snyk, composer audit), and onboarding risk for whoever inherits the repo.
• Migration estimation rubric: The documented capabilities — conversion of assertions, setup/teardown preservation, data providers, Laravel test patterns — are useful as evaluation criteria when comparing current migration options. Use them to write the scoring rubric; not as a reason to adopt this package.
• Roadmap sequencing guardrail: Reinforces a rule that test-framework migration must never be stacked with a PHP or Laravel upgrade in the same window. Stacked changes make failures unattributable and burn review capacity — a PM-level scheduling constraint, not an engineering detail.

When to Consider This Package

• Only when a Pest migration is already funded and staffed. No funded migration means no use case; a tooling spike must not become the tail that wags the migration dog.
• As a historical reference, not a dependency. If the team is scoping the migration, vendor or fork the code for a short spike to study earlier codemod patterns — never as a committed require-dev entry on a long-lived branch.
• As a comparison arm in a spike. Run it alongside a maintained successor (Pest's own tooling, Rector rules) on one representative test directory. At that scale, comparing two tools is cheaper than committing to either.
• When you can fully own it. A named engineer with capacity to audit, patch, and permanently maintain a fork — accepting it likely will not resolve against PHP 8.x / Laravel 10+ or current Pest APIs without constraint overrides.
• Look elsewhere when: you need active maintenance, modern PHP/Pest compatibility, community support, a repeatable process, or anything that has to survive past this one migration. Prefer Pest's first-party tooling, Rector-based codemods, or a narrowly scoped internal script tailored to your suite.
• Resolve the description conflict before spending PM time. The package blurb describes snapshot testing (expect()->toMatchSnapshot(), --update-snapshots), while the name and release notes describe a PHPUnit→Pest codemod. These are two different products. Mismatched marketing is itself a quality signal — find out what this actually does before booking anyone's time.
• Do not consider it for: new projects, long-lived test infrastructure, CI pipelines requiring support, or any scenario where a maintained migration path matters.

How to Pitch It (Stakeholders)

• Executives: pestphp/drift is not a strategic dependency and should not be adopted. It is an archived, low-adoption, dev-time migration helper from 2020 — no releases since September 2020, zero dependents, low composite score. Blast radius is genuinely small: dev-only, never in the request path, never touching production data. But the value is one-time at best, and the ownership cost is permanent. Recommendation: fund a two-day spike comparing maintained codemod options against manual conversion on one representative test directory, and treat Drift as a reference point, not a candidate.
• Engineering: Treat this as historical, not installable. Expect a Composer resolution fight before a single test is converted, since the package targets the PHP 7.2/7.3 and Laravel 6/7 era. The highest-severity risk is silent semantic drift: a codemod that mis-translates data providers, @depends, setUp/tearDown hooks, trait fixtures, or exception expectations can produce tests that pass while asserting less than the originals. Green CI is not evidence of correctness. The only defensible pattern is a time-boxed throwaway spike on a scratch branch: run it against the most syntactically varied test directory, hand-review every diff, measure conversion rate / manual-repair rate / repair time, then delete the tool from the branch. Do not sequence this alongside a framework upgrade.
• Product/QA: Keep phpunit.xml and the PHPUnit binary intact throughout any evaluation and run both suites in parallel as parity evidence. Budget review as a first-class line item, not an afterthought: N converted files require N reviews, and under-resourcing review is exactly what turns a convenience into a correctness incident. Expect a tail of files the tool cannot convert, plus partial conversions that are worse than none because they look finished.