Value for test.exclude is mutated in place

[jacobtylerwalls]

Describe the bug

The relevant bit of my config looks like:

const exclude = ['**/node_modules/**'];
export default defineConfig({
  test: {
    exclude,
    coverage: {
      exclude,
      // This works:
      // exclude: [...exclude],
    },
  },
});

When migrating to v3, running with --run --coverage broke test discovery.

Copying the array fixes it, which suggests to me that test.exclude is being mutated in place. Repro attached.

Could this be fixed to allow upgrading from v2 to v3 without configuration changes? Thanks!

Reproduction

https://stackblitz.com/edit/vitest-dev-vitest-gqrbamjs?file=vite.config.ts

System Info

System:
    OS: macOS 15.3.2
    CPU: (10) arm64 Apple M2 Pro
    Memory: 81.77 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.17.0 - ~/.nvm/versions/node/v20.17.0/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 10.9.0 - ~/.nvm/versions/node/v20.17.0/bin/npm
  Browsers:
    Chrome: 134.0.6998.166
    Safari: 18.3.1
  npmPackages:
    @vitest/coverage-v8: 3.1.0 => 3.1.0 
    vitest: 3.1.0 => 3.1.0

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[AriPerkkio]

This was likely introduced in

• fix(coverage)!: always exclude test files #7254

While this side effect is unintentional and easy to fix, I'm not sure what's Vitest's general view on mutating the configuration options. Should we copy all arrays from user's config file before modifying them?

[hi-ogawa]

While this side effect is unintentional and easy to fix, I'm not sure what's Vitest's general view on mutating the configuration options. Should we copy all arrays from user's config file before modifying them?

Yeah, it looks like it's not currently consistent in resolveConfig, but I think we can try to spread the array first. Technically mutation can also happen in object, but I guess that one is less likely hit this case.