HowTo: Monorepo / Projects with Node and Browser Tests + vscode integration

[gossi]

Heyo,

I'm a happy vitest user, but also I'm confused by how to properly set this up on a heterogeneous monorepo.

Given

• Multiple packages (currently 19, 10 with tests)
• Some have node tests
• Some have browser tests
• Some have both sorts of tests

Goal

• Ideally a root vitest config, that can run them all
• I would want to run them individually (per package that I'm working on)
• Coverage for all of them
• Browser and node tests
• Usage: CLI, VSCode and Vitest UI
• Browser tests:
  • headless on CI and CLI
  • wdio/playwright on CI
  • Use preview provider when used with vitest UI

I also think, vitest might not provide yet everything I need for that (that's ok, incremental adoption is fine).

What I learned

• Some configs options are only available globally, eg. coverage

• In a package, that has both sorts of tests, I'm doing this at the moment:

  // package/both/vitest.config.ts
  export default defineConfig({
    test: {
      projects: [
        './vitest.config.node.ts',
        './vitest.config.browser.ts'
      ]
    }
  });

  that is ok, to run the tests from within that package, but that file seems to be ignored from root config (even if directly pointed at it, I guess due to project-ception, since this is invalid).

  Using this from the global root config works though: packages/both/vitest.config.{node,browser}.ts

• Pointing to browser tests like above, the execution fails from repo root. It works from within the package

• VScode extension fails the same way as the CLI, when browser and node tests are mixed (seems like a UI to the CLI here, would make totally sense)

• VScode extension lists the tests based on the folder structure... unless you give them a name (as what seems needed for the hybrid packages). The listing then looks weird (I guess you could give all projects a name then).

• Vitest UI is giving the better visuals and gives vibrant color badges

• Vitest UI run from root also fails on the browser tests (same as CLI and vscode above)

Guidance

There is docs for sure to explain individual fields or explain the syntax for configuring the projects, that's great. The problem I'm running into is some sort of reverse engineering how these configs work, when applied.

What I'm looking for is some guidance how to configure these sort of projects, in form of examples or best practices.

What is also sometimes find confusing is, what process is doing what. Eg. you can start vitest in your terminal ... but also in VScode? Do they share the same process? Can I start the same in vscode but open the vitest UI in the browser? I regularly find myself in the wrong spot 🙈

Hope some docs can bring relief here. Wanna bring it up for discussion at first. Maybe my goals are contrary to the design for vitest?

Later issues can be derieved.

[gossi]

Addition to the confusion:

From where are paths resolved? Is it from the package directory where there is a vitest.config.js? Is it from the repo root?

I have the feeling I am in a package, but it is driven from repo root (even when that particular package isn't part of root projects) 🤔😵

[sheremet-va]

From where are paths resolved? Is it from the package directory where there is a vitest.config.js? Is it from the repo root?

All paths are resolved relative to the project root. If the project is inside a workspace, it will be resolved relative to that project.

If the option is only available inside the root config, it is resolved once relative to the top-level root (which is usually cwd, but can be changed via the config.root option).

[sheremet-va]

What is also sometimes find confusing is, what process is doing what. Eg. you can start vitest in your terminal ... but also in VScode? Do they share the same process? Can I start the same in vscode but open the vitest UI in the browser? I regularly find myself in the wrong spot 🙈

They are all isolated processes. vscode specifically manually disables the UI so it's never annoyingly opened when you open vscode.

Vitest UI is giving the better visuals and gives vibrant color badges

It is unfortunate, but vscode doesn't allow anything except text in test items.

[mrmckeb]

@sheremet-va For teams using build systems (Lage, Nx, Turborepo, etc), tests are often expected to be run from the packages themselves, not the workspace.

To confirm, are both of these structures now supported by the VS Code extension? And a combination of both is not supported?

// Running commands from the workspace only

vitest.config.ts -> projects

packages/foo/vitest.config.ts

packages/bar/vitest.config.browser.ts
packages/bar/vitest.config.node.ts

packages/qux/vitest.config.ts

// Running commands from packages only

packages/foo/vitest.config.ts

packages/bar/vitest.config.ts --> projects
packages/bar/vitest.config.browser.ts
packages/bar/vitest.config.node.ts

packages/qux/vitest.config.ts

If so, it might be worth updating the examples and README to show the different configurations, and explain when you might use each?

I'd be happy to pick up that task too!

[sheremet-va]

Sorry for the very late reply. The vscode extension does indeed support this. By default, it loads every config as a separate child_process. If this config produces projects, it will support those projects. The extension however will ignore any projects created inside another projects (this was someones edge case we had to workaround).

If the project uses a config, Vitest will not load that config as a separate process. In your second example there will be 3 processes - for foo, bar and qux. In your first example there will be a single process - the root one.

[mrmckeb]

Thank you!