Drift Laravel Package

Technical Evaluation

Architecture fit. pestphp/drift is a development-time codemod — "drifting you to Pest" — that rewrites PHPUnit class-based test files into Pest's functional syntax. It is not a runtime dependency, not middleware, not a service provider on the request path. From a blast-radius standpoint this is the safest category of package that exists: it cannot reach production, cannot touch customer data, and any defect is confined to the test suite and CI. That is the entire case in its favor. Everything else in the signal set is negative: 29 stars, zero dependents, archived upstream, last release 2020-09-11, composite score ~1.17.

There is also a documentation defect that must be resolved before any engineering time is spent. The indexed package blurb describes snapshot testing (expect()->toMatchSnapshot(), --update-snapshots, baseline accept/reject, CI-friendly exit codes), while the repository name, release notes, and developer assessment describe a PHPUnit→Pest migration tool. These are two different products. Mismatched marketing is itself a maintenance-quality signal, and it means the first diligence question is simply: what does this package actually do? Until answered, any evaluation is evaluating a guess.

Integration feasibility. Nominally a require-dev line plus a console invocation against a target directory. In practice the 2020 vintage is the binding constraint. The package targets the PHP 7.2/7.3 and Laravel 6/7 era; a modern PHP 8.2+/Laravel 10+ application will likely fail Composer resolution without constraint overrides or a fork. Zero dependents is a meaningful negative signal here — there is no public evidence of anyone running this successfully against a contemporary codebase, which means your spike is the first field test, not a validation of known-good behavior.

Technical risk, in descending order of severity:

1. Silent semantic drift. A codemod that mis-translates a data provider, an @depends annotation, a setUp/tearDown lifecycle hook, a trait-based fixture, or an exception expectation can produce tests that pass while asserting less than the originals. Green CI is not evidence of correctness — it is evidence the tests ran. This is the risk that should drive the decision, because it is invisible by construction and it corrupts the artifact the team relies on to ship safely.
2. Abandonment. Archived means no CVE response, no PHP-version compatibility work, no bug fixes, no issue triage. Dev-only bounds supply-chain exposure, but SCA tooling (composer audit, Dependabot, Snyk) will flag it and generate recurring dependency-review noise for as long as it sits in composer.json.
3. Coverage gaps. PHPUnit's circa-2020 feature surface is broad. A small tool from that period will not have handled all of it. Expect a long tail of unconvertible files plus partial conversions that are worse than none because they look finished.

Key questions.

• Is the team actually migrating PHPUnit→Pest, or is this speculative? No funded migration means no use case.
• What does the package genuinely do — snapshot assertions or test migration? This determines whether it has any relationship to the roadmap at all.
• What is our suite's feature surface — data providers, @depends, abstract base test classes, custom assertions, mocking-heavy tests? High-complexity suites should not go through an unmaintained codemod.
• What maintained alternatives exist today? Pest's first-party migration tooling and Rector-based codemods have both evolved since 2020 and should be default candidates. Verify, don't assume.
• Is there a named owner willing to fork and maintain if the tool proves useful? If not, do not start.
• Does it resolve against our actual PHP/Laravel constraints? A ten-minute check that kills the evaluation cheaply if the answer is no.

Integration Approach

Stack fit. Composer require-dev, PHP/Laravel only — no database, queue, or infrastructure touchpoints. It fits the stack in the narrow sense that it is installable in principle. It does not fit in the sense that matters: resolving against a currently supported PHP and framework version. Scope the work assuming a Composer-resolution fight precedes the first converted test.

Migration path. Do not install it as a durable dev dependency. The only defensible pattern is a time-boxed, throwaway spike:

1. Branch off; do not touch main.
2. Run the tool against one representative test directory — pick the most syntactically varied one, not the easiest, or the conversion rate you measure will be fiction.
3. Diff output against originals and hand-review every file.
4. Measure three numbers: percent of files converted, percent of converted files needing manual repair, and repair time per file.
5. Decide on evidence, then delete the tool from the branch.

If a maintained successor exists, run the same spike on two tools in parallel. At this scale, comparison is cheaper than commitment.

Compatibility. Assume incompatibility until proven. Pin to a specific commit if a fork is used; the last tag is 2020 and will not track PHP minor-version changes. Pest 2.x/3.x-era APIs are almost certainly outside what this tool emits, meaning the output may not even be idiomatic for the framework you are migrating to. Keep phpunit.xml and the PHPUnit binary intact throughout so both suites can run in parallel for parity evidence.

Sequencing. This belongs at the front of a Pest migration, behind a go/no-go on the migration itself, and before any test-suite restructuring. It must not run alongside a Laravel or PHP upgrade — stacking a framework upgrade and a test-framework codemod in one window makes failures unattributable and turns debugging into archaeology. If the migration is not already funded and staffed, close the evaluation here; do not let a tooling spike become the tail that wags the migration dog.

Operational Impact

Maintenance. Upstream maintenance is zero by definition. Any real use implies a fork or vendored copy under team ownership. A small codemod is tractable to fork — days, not weeks — but it is permanent work in service of a one-time transformation. That is a bad ownership trade: indefinite obligation, finite value. The correct posture is consume-once-and-discard.

Support. None. No issue triage, no security response, no compatibility patches. The saving grace is that a dev-only tool cannot expose production attack surface; the cost is confined to CI reliability and scanner noise. For a TPM that means the burden lands on your own on-call and platform engineers, not on any vendor or upstream maintainer. Budget it as an internal support line, not a free dependency.

Scaling. Not a scaling concern in the conventional sense — it does not run in production or per-request once migration completes. Its only "scale" is the size of the suite it chews through, once. The scaling question that actually matters is review capacity: N converted files require N reviews, and that cost grows linearly with suite size regardless of tool quality. Budget review as a first-class line item, because under-resourcing it is precisely what converts this from a convenience into a correctness incident.

Failure modes.

• Composer resolution failure on modern PHP/framework constraints — highest probability, cheapest to test, test it first.
• Partial or incorrect conversion producing tests that pass while asserting less than the original — highest severity, invisible, erodes the safety net that gates every future release.
• Silent no-op or skipped files that reviewers assume were converted — mitigated by diffing every file, never by trusting the tool's summary.
• Scanner/audit noise and dependency-review friction from an archived package — mitigated by never committing it to composer.json.
• Second-order: the spike succeeds, gets merged prematurely, and the team inherits a fork nobody owns.

Ramp-up. Low for a TPM to reason about, moderate for engineers to execute honestly — the tool itself is trivial to invoke, but the discipline of reviewing every diff and running dual suites is the actual work. A two-day spike with named engineering capacity is the right envelope: day one for resolution and a first conversion pass, day two for hand-review and measurement.

Recommendation. Treat pestphp/drift as a historical reference, not a dependency. It has no product surface unless a PHPUnit→Pest migration is already funded. Resolve the description conflict, then run a two-day throwaway spike comparing Drift against today's maintained codemod options on one representative directory. Fund the migration decision first; fund this tool never.