Selecting Internal Config File when Running in Workspace?

[amitz]

Hello! 😄

Please consider the following mono-repo structure:

|-- src
|   |-- projectA
|       |-- test
|            |-- integration
|            |-- unit
|       |-- package.json
|       |-- vitest.config.integration.ts
|       |-- vitest.config.unit.ts
|   |-- projectB
|       |-- test
|            |-- integration
|            |-- unit
|       |-- package.json
|       |-- vitest.config.integration.ts
|       |-- vitest.config.unit.ts
|-- vitest.shared.unit.ts
|-- vitest.shared.integration.ts
|-- vitest.workspace.ts

The vitest.workspace.ts refers to both projectA and projectB:

export default [
  'src/*/vitest.config.{unit,integration}.ts'
]

The package.json - in both projects, has test targets:

    "test:unit": "vitest --config=vitest.config.unit.ts",
    "test:integration": "vitest --config=vitest.config.integration.ts",

The vitest.config.unit.ts file in each project uses mergeConfig to read some baseline options from the root's vitest.shared.unit.ts. For example, the root shared config will set restoreMock: true and will also include only tests within the unit directory. The vitest.config.integration.ts will do about the same (just mergeConfig the root's vitest.shared.integration.ts file). The reason for that is that we want all unit/integration tests to have a shared set of configuration, but I also want developers to be able to set their own options inside the project (like testTimeout or setupFiles for example).

This works wonderfully when running npm test:unit or npm test:integration within the projects themselves.

But this being a mono-repo, during merge requests, I want to run BOTH kinds of tests, from the root and using the --changed flag. There is where things break, because it seems that vitest, will pick the first config file alphabetically it can find on the each project root and use that. I'm looking for some way to to effect which config files are used internally, when running from within a workspace (something like the --config in the context of a workspace).
Is there any resolution around this?

[AriPerkkio]

it seems that vitest, will pick the first config file alphabetically it can find on the each project root and use that

Would be great to get a reproducible project for this to try different solutions but here are couple ideas:

1. Do the src/*/vitest.config.{unit,integration}.ts files have unique test.name property? If not, does it help if it's added?

2. Does this work? Maybe with the test.name property?

export default [
  'src/*/vitest.config.unit.ts',
  'src/*/vitest.config.integration.ts'
]

3. Does it work if you define project explicitly like

import { defineWorkspace } from 'vitest/config'

// Generating this could be automated with `node:fs`
export default defineWorkspace([
  {
    test: {
      name: 'Project A Unit',
      config: './src/projectA/vitest.config.unit.ts',
    },
  },
  {
    test: {
      name: 'Project A Integration',
      config: './src/projectA/vitest.config.integration.ts',
    },
  },
  {
    test: {
      name: 'Project B Unit',
      config: './src/projectB/vitest.config.unit.ts',
    },
  },
  {
    test: {
      name: 'Project B Integration',
      config: './src/projectB/vitest.config.integration.ts',
    },
  },
])

[amitz]

Hello @AriPerkkio! Thanks for the quick answer 🏅

Would be great to get a reproducible project for this to try different solutions

Sure!

Do the src/*/vitest.config.{unit,integration}.ts files have a unique test.name property? If not, does it help if it's added?

I don't use the name property, no. I couldn't find what name does exactly or what can interact with it in the documentation (could only find browser.name). Can I use the same name (for example integration in all the projects and then call those specifically? with something like --project?

Regarding question 2-3, you're asking if this works. But I'm a bit confused on HOW it should work. Assuming you have two configurations on the same file - the current scenario where Vitest pick the first config in project it can alphabetically find and use makes sense. But I want to select a specific config file for all projects from the root.

[AriPerkkio]

Something like this should work. Though your repo doesn't have vitest.config.ts for the workspace.

import { readdirSync } from "node:fs";
import { defineProject, defineWorkspace } from 'vitest/config'

const projects = readdirSync("./src");

export default defineWorkspace(
  projects.map((project) => [
    defineProject({
      test: {
        name: `${project} Unit`,
        root: `src/${project}`,
        config: `src/${project}/vitest.config.unit.ts`
      },
    }),
    defineProject({
      test: {
        name: `${project} Integration`,
        root: `src/${project}`,
        config: `src/${project}/vitest.config.integration.ts`
      }, 
    }),
  ]).flat()
)

As the project is currently not using Vitest workspaces you could even simplify this by using just pnpm to run the commands:

  "scripts": {
    "test:unit:ci": "pnpm run --recursive --stream test:unit --run",
    "test:integration:ci": "pnpm run --recursive --stream test:integration --run"
  },

[amitz]

Though your repo doesn't have vitest.config.ts for the workspace.

I didn't see the value of having one, because I want each project to use its own unique config, and there is no one config that fits all projects. For example, if projectA uses setupFiles and projectB won't - that's not something I can use on the root vitest.config.ts? Correct me if I'm wrong?

Something like this should work.

So the main idea is to generate the Workspace file dynamically, and then run the integration tests with something like pnpm vitest --projects=*-integration?

As the project is currently not using Vitest workspaces you could even simplify this by using just pnpm to run the commands:

I'm a bit confused about the suggested solution. The project uses Vitest workspace. You're suggested solution while working, won't allow me to have a single report at the end (I can use the merge option but..). The current solution I'm using is very similar to what you suggested using nx - but I wanted to use the native workspace feature with the --changed flag.

[AriPerkkio]

I think you are actually running into #5530 here. Once that's fixed this will start working.

I didn't see the value of having one, because I want each project to use its own unique config, and there is no one config that fits all projects.

Those configurations are defining options that work only in Workspace's root vitest.config.ts, e.g. coverage. Coverage is reported for whole workspace so it's not possible to define it in projects.

[amitz]

I think you are actually running into #5530 here. Once that's fixed this will start working.

Ha! Thank you for linking that issue. The workaround mentioned (using a different directory for each config file) pushed me in the right direction. This leads to another issue which you touched upon with your example - the working dir is where the config file is. So I had to pass the --root option inside the project, and modify the include list externally (because when running from the project itself, you're not running from the "root" dir, or at least where Vitest thinks the root dir is).

I modified the repo above with a working example in case anyone might find it useful.

This was rather complex to set up and a bit hacky. I believe #5530 should be more than a minor bug. Will mention it on the bug itself.

Thanks for all the help @AriPerkkio !