Verify canary release

• I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

https://github.com/kenfdev/study-turborepo-vitest

Which canary version will you have in your reproduction?

2.5.5-canary.0

Environment information

turbo 2.5.5-canary.0

CLI:
   Version: 2.5.5-canary.0
   Path to executable: /Users/fukuyamaken/tmp/turbo/node_modules/turbo-darwin-arm64/bin/turbo
   Daemon status: Running
   Package manager: npm

Platform:
   Architecture: aarch64
   Operating system: macos
   WSL: false
   Available memory (MB): 9520
   Available CPU cores: 8

Environment:
   CI: None
   Terminal (TERM): xterm-256color
   Terminal program (TERM_PROGRAM): WezTerm
   Terminal program version (TERM_PROGRAM_VERSION): 20240203-110809-5046fc22
   Shell (SHELL): /bin/zsh
   stdin: false

Expected behavior

According to the official docs about Vitest here, npm test should respect the root vitest.config.ts .

Actual behavior

Even though I intentionally make the vitest.config.ts an invalid file, the test does not fail. If I individually execute npm run vitest, the test fails, saying the vitest.config.ts is invalid.

IIUC, turborepo executes the test script in individual projects, hence the root vitest.config.ts doesn't matter. If so, why is the hybrid approach intended for? The "Vitest Project Feature" doesn't seem to have any meaning at the moment.

To Reproduce

Just run npm run test from the root of the project.

Additional context

Not sure why but npx create-turbo@latest --example with-vitest has type errors in the root vitest.config.ts.

This is what gets generated currently:

import { defineConfig } from 'vitest/config';
import { sharedConfig } from '@repo/vitest-config';

export default defineConfig({
  ...sharedConfig,
  projects: [
    {
      name: 'packages',
      root: './packages/*',
      test: {
        ...sharedConfig.test,
        // Project-specific configuration for packages
      }
    },
    {
      name: 'apps',
      root: './apps/*',
      test: {
        ...sharedConfig.test,
        // Project-specific configuration for apps
        environment: 'jsdom',
      }
    }
  ]
});

The config uses top level projects but this is not documented in the Vitest official docs: https://vitest.dev/guide/projects.html#defining-projects

It's under the test property. I doubt this is causing any trouble, but just some additional context about the --with-vitest template.