TIA: change detection misses all changes when the Pest project is a subdirectory of the git repository (monorepo)

[officialsyntec]

What happened

In a monorepo where the Pest project lives in a subdirectory of the git repository (e.g. backend/), TIA never detects any PHP source change. In the worst case it replays the previous results as passing without executing the tests affected by the change.

repo/                <- git root
├── frontend/
└── backend/         <- Laravel app, composer.json, pest runs here
    ├── app/
    └── tests/

Reproduction:

1. Record a baseline: PEST_ALLOW_XDEBUG=1 XDEBUG_MODE=coverage vendor/bin/pest --tia (from backend/, all green, graph written).
2. Make a semantic change to backend/app/Services/Billing/PartialInvoiceService.php (e.g. add a private const).
3. Run vendor/bin/pest --tia again.

Expected: the tests covering that file are re-executed (in our suite: 40 tests across 4 files).
Actual: Tests: 1669 passed (…, 1669 replayed) in ~3s — the change maps to zero tests and everything is replayed as unchanged.

With no coverage driver loaded the failure is the safe-but-slow variant instead: WARN Detected PHP source changes but no coverage driver is available followed by a full-suite run on every invocation.

Root cause

src/Plugins/Tia/ChangedFiles.php collects changed paths via:

• workingTreeChanges() → git status --porcelain -z --untracked-files=all (cwd = project root)
• diffSinceSha() → git diff --name-only <sha>..HEAD

Both git commands print paths relative to the repository root (backend/app/Services/...), regardless of cwd. Downstream these are consumed as project-relative paths:

• currentHash() prepends the project root → …/backend/backend/app/... → is_file() false
• the dependency-graph keys are project-relative (app/Services/...) → the changed path never matches an edge → affected set is empty

Verified identical logic in v4.7.5 (installed) and v5.0.0 (GitHub source). Projects whose composer root equals the git root never notice, since both path notions coincide.

Proof it is exactly this

Creating a throwaway git repository inside backend/ (making project root == git root) and repeating the same experiment yields correct behavior immediately: Tests: 1669 passed (…, 40 affected, 1629 replayed) in ~100s. Removing the inner repo restores the broken behavior.

Suggested fix

Ask git for the prefix once (git rev-parse --show-prefix, empty at repo root) and strip it from every path returned by workingTreeChanges() / diffSinceSha() before they are compared with project-relative graph keys; paths outside the prefix (sibling packages, e.g. frontend/…) can be discarded or kept for the structural-change checks.

Environment

• Pest v4.7.5 (same code confirmed in v5.0.0)
• PHP 8.4.10, Laravel 12.64, PostgreSQL, macOS (darwin arm64)
• Layout: Laravel app in backend/ subdirectory of the git repo, tests/Pest.php maps Tests\TestCase onto Feature + Unit, suite is 100% functional Pest style (1669 tests)

[officialsyntec]

Root cause, traced in pestphp/pest v4.7.5 — src/Plugins/Tia/ChangedFiles.php.

The mismatch: both git invocations run with $this->projectRoot as the working directory, but git reports paths relative to the repository root, not the CWD.

// :239
['git', 'diff', '--name-only', $sha.'..HEAD'],
$this->projectRoot,

// :257
['git', 'status', '--porcelain', '-z', '--untracked-files=all'],
$this->projectRoot,

Those results are then treated as project-relative:

// :50
$absolute = $this->projectRoot.DIRECTORY_SEPARATOR.$relativePath;
// :70
$absolute = $this->projectRoot.DIRECTORY_SEPARATOR.$file;

The docblock at :18 states the contract explicitly — @param array<int, string> $files project-relative paths. — which is exactly what git does not deliver here.

Concrete result with projectRoot = /repo/backend and git returning backend/app/Services/Billing/PartialInvoiceService.php:

/repo/backend/backend/app/Services/Billing/PartialInvoiceService.php

is_file() is false, the entry is discarded, the changed-file set comes out empty, and every test is replayed. That is the silent-pass behaviour in the report: no failure, no warning, just a suite that did not run.

Verified from a repo root of /repo, with the Pest project in backend/:

command, CWD = backend/	output
git rev-parse --show-prefix	backend/
git diff --name-only	docker-compose.yml (repo-root-relative)
git status --porcelain --untracked-files=all	?? backend/app/… (repo-root-relative)

On the fix: --relative handles git diff and has the bonus of scoping results to the subdirectory, but git status has no such flag — --porcelain is documented as repo-root-relative and git status --relative is rejected outright. So the uniform fix is to resolve the prefix once and strip it from both:

$prefix = trim(shell_output(['git', 'rev-parse', '--show-prefix'], $this->projectRoot));
// 'backend/' at a subdirectory root, '' at the repository root
$files = array_map(
    fn (string $f): string => $prefix !== '' && str_starts_with($f, $prefix)
        ? substr($f, strlen($prefix))
        : $f,
    $files,
);

Paths outside the prefix (frontend/…, root-level files) then fall outside the project and can be dropped rather than mapped to a nonexistent path.

Worth noting the failure is silent and fails open, so a monorepo CI running --tia reports green while executing nothing. A guard for "graph is non-empty but zero changed files resolved" would surface it even where the prefix handling is not yet fixed.

[johnbacon]

Opened #1805 implementing the prefix translation suggested here — ChangedFiles resolves git rev-parse --show-prefix once and converts at each git boundary (stripping repo-relative output, prefixing git show input), with the repository-root guard removed. Covered by nested-repo fixture tests, including the silent stale-replay reproduction from this issue.