Motivation
When changing or optimizing a local package, running only that package's own tests or benchmarks can miss regressions in downstream dependents. A repository-local affected-test selector would make it easier to validate behavior and performance across the packages that use the changed code.
This is inspired by Vitest's related command.
Detailed Description
The proposed interface is:
moon test --related PATH...
moon bench --related PATH...
The implementation in #1855 currently maps each ordinary source path to its owning local package, then selects that package and its reverse local package-dependency closure. It is deliberately package-graph based: precise same-package file or symbol dependencies would require additional compiler/build metadata.
Manifests are handled conservatively by selecting the corresponding module or workspace. Explicit *_test.mbt and *_wbtest.mbt inputs currently use the existing file-level test filter.
Before finalizing the implementation, we should agree on the user-facing contract:
- Should
--related be supported by both moon test and moon bench?
- Which dependency edges define “related”? In particular, should link-time relationships such as virtual-package overrides participate alongside ordinary package imports?
- When the input itself is a test file, should Moon run only that file, the owning package, or the reverse package closure?
- Should paths outside local packages be ignored with a diagnostic or rejected as errors?
- Which existing selectors should compose with
--related (for example --filter, target selection, and package scoping)?
A future, more precise version could use compiler-provided file-to-file or symbol-to-file dependency information, but that is not required for the initial package-level behavior.
Related Issues
Checklist
Motivation
When changing or optimizing a local package, running only that package's own tests or benchmarks can miss regressions in downstream dependents. A repository-local affected-test selector would make it easier to validate behavior and performance across the packages that use the changed code.
This is inspired by Vitest's related command.
Detailed Description
The proposed interface is:
The implementation in #1855 currently maps each ordinary source path to its owning local package, then selects that package and its reverse local package-dependency closure. It is deliberately package-graph based: precise same-package file or symbol dependencies would require additional compiler/build metadata.
Manifests are handled conservatively by selecting the corresponding module or workspace. Explicit
*_test.mbtand*_wbtest.mbtinputs currently use the existing file-level test filter.Before finalizing the implementation, we should agree on the user-facing contract:
--relatedbe supported by bothmoon testandmoon bench?--related(for example--filter, target selection, and package scoping)?A future, more precise version could use compiler-provided file-to-file or symbol-to-file dependency information, but that is not required for the initial package-level behavior.
Related Issues
Checklist