feat(cli): support --related in vitest list - #11015
Conversation
c17c296 to
75459d9
Compare
|
Hello @joaovitoras. Your PR has been labeled To keep your PR open, please follow these steps:
Please, do not generate or format the response with AI. If you do not speak English, reply in your native language or use translation software like Google Translate or Deepl. If the response is generated, the PR will be closed automatically. These measures help us reduce maintenance burden and keep the team's work efficient. See our AI contributions policy for more context. |
✅ Deploy Preview for vitest-dev ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for vitest-dev ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
7053f9c to
b8b4d7c
Compare
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
This PR was authored and reviewed by me. Copilot was used only as an assistant, not as an autonomous agent. The change was manually designed and tested by me |
| options.passWithNoTests ??= true | ||
| args = [] | ||
| } | ||
| if (arrayArgs[2] === 'list' && options.findRelatedTests) { |
There was a problem hiding this comment.
Half the changes in this PR would be removed if you just named it related. Why do we need to follow jest naming?
There was a problem hiding this comment.
We don't need to go this way, it was just a strong inspiration
Working on it
There was a problem hiding this comment.
You were right. Renaming it to related removed the separate Jest-inspired option and its API/config plumbing. The remaining handling is needed because, for list, --related is a boolean flag while its positional arguments must be converted into the existing related: string[] runtime option, rather than treated as test filters
What do you think about this? Do you recommend I follow a different approach?
Description
vitest relatedruns tests affected by source files, but tooling that only needs to inspect the affected test set had no equivalentlistworkflow.This is useful for CI orchestration that needs to determine the affected test files without executing the tests. Coverage includes direct and transitive dependencies, multiple related source files, file-only output, JSON output, and CLI parsing.
Use case - Sharding related tests
In CI, a pipeline can identify the test files affected by a change and distribute only those files across available workers. For example,
vitest list --related --filesOnly <changed-files>produces the related test-file list. The pipeline can split it into balanced groups and run each group in a separate shard.Usage
Resolves #11016
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
pnpm-lock.yamlunless you introduce a new test example.Tests
pnpm test:ci.Documentation
pnpm run docscommand.Changesets
feat:,fix:,perf:,docs:, orchore:.