Fix: nested test projects - #8273

✅ Deploy Preview for vitest-dev ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	3af8a4c
🔍 Latest deploy log	https://app.netlify.com/projects/vitest-dev/deploys/686c888577bb4800085e9ed0
😎 Deploy Preview	https://deploy-preview-8273--vitest-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

I don't like this. The projects glob is intentionally dead simple. packages/* matches packages/business, so it should create a project there. If you don't want it to be treated as a project, add a negated glob !packages/business

Thank you for your feedback! I understand your consideration of keeping the project glob simple.

Regarding the Complexity of Manual Exclusion

You mentioned using the negative glob !packages/business, but in reality, this won't work in the current situation because 'packages/business/*' will also be excluded. To correctly exclude nested projects, users need to use:

['packages/!(business)', 'packages/business/*']

This syntax is not intuitive for many developers, especially in large monorepos where multiple such exclusion rules may need to be maintained, which imposes a certain mental burden.

The Significance of the Current Solution

This modification mainly addresses the issue where developers' expectations do not match the actual behavior:

1. Intuitiveness: When users configure packages/business/*, their expectation is to "only run sub-projects under business" rather than "run business itself + sub-projects".
2. Avoid Duplicate Execution: In our actual projects, such duplicate execution has led to doubled testing time and confusing reports.
3. Consistency with Common Usage Patterns: In monorepos, there are usually root-level configurations and sub-project-specific configurations.

Improvement Suggestions

I fully understand your concern about maintaining simplicity. Could we consider making this feature an optional one? For example:

export default {
  projects: {
    patterns: ['packages/*', 'packages/business/*'],
    deduplication: true // Defaults to false for backward compatibility
  }
}

This way, the simplicity of the existing behavior is preserved, while providing an option for users who need such intelligent handling.

What do you think of this optional approach? Looking forward to your feedback.

@sheremet-va What about inline configurations ?

Let's say the root config is projects: ['packages/*'] and each package configure several inline projects to run unit tests or e2e tests, for example.

In CI, you may want to run e2e tests using the docker image provided playwright along with vitest --run --project='*:e2e'. And run the non e2e tests on the node image.

Currently, projects do not run nested projects, inline or not.

This syntax is not intuitive for many developers, especially in large monorepos where multiple such exclusion rules may need to be maintained, which imposes a certain mental burden.

Then perhaps adding the example to the documentation is enough.

Magically removing files from the glob you specified is more confusing than the current behaviour where we process everything that your glob matches.

@sheremet-va What about inline configurations ?

This PR has nothing to do with inline configuration.

That’s true, you’ve got a point.