feat: support test projects

[9aoy]

Summary

Support define & run multiple test projects via projects configuration. This allows users to define and run tests across multiple project directories with different configurations, enabling better organization of test suites in monorepo structures.

import { defineConfig } from '@rstest/core';

export default defineConfig({
  projects: ['packages/core', 'examples/node', 'examples/react'],
  globals: true,
  setupFiles: ['./scripts/rstest.setup.ts'],
});

Related Links

Checklist

• Tests updated (or not required).
• Documentation updated (or not required).

[netlify]

✅ Deploy Preview for rstest-dev ready!

Name	Link
🔨 Latest commit	e230567
🔍 Latest deploy log	https://app.netlify.com/projects/rstest-dev/deploys/68834c6c2ac1780008c54969
😎 Deploy Preview	https://deploy-preview-420--rstest-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.

[Copilot]

Pull Request Overview

This PR implements support for multiple test projects in rstest by adding a projects configuration option. This allows users to define and run tests across multiple project directories with different configurations, enabling better organization of test suites in monorepo structures.

Key changes include:

• Added projects configuration support to define multiple test directories
• Updated core types to include project information throughout the testing pipeline
• Modified build and execution logic to handle multiple projects concurrently

Reviewed Changes

Copilot reviewed 24 out of 24 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
rstest.config.ts	Updated configuration to use projects array instead of include patterns
packages/core/src/types/*.ts	Added project property to core types (TestCase, TestSuite, TestResult, WorkerContext)
packages/core/src/core/*.ts	Modified core functions to handle multiple projects and project-specific configurations
packages/core/src/runtime/**/*.ts	Updated runtime components to track and pass project information
packages/core/src/pool/*.ts	Enhanced pool management to support project-aware test execution
packages/core/src/cli/*.ts	Refactored CLI to support project resolution and initialization
packages/core/src/core/plugins/*.ts	Updated plugins to work with environment-specific configurations

[Copilot]

The nullish coalescing assignment (??=) is used here, but testStart is declared as let testStart: number; which means it's undefined initially. This line should be moved outside the loop and executed once before the Promise.all to ensure consistent timing measurement.

Suggested change

	let testStart: number;
	const buildStart = Date.now();
	const returns = await Promise.all(
	context.projects.map(async (p) => {
	const { entries, setupEntries, assetFiles, sourceMaps } =
	await getRsbuildStats(p.name);
	testStart ??= Date.now();
	const testStart = Date.now();
	const buildStart = Date.now();
	const returns = await Promise.all(
	context.projects.map(async (p) => {
	const { entries, setupEntries, assetFiles, sourceMaps } =
	await getRsbuildStats(p.name);

[Copilot]

Using the non-null assertion operator (!) on testStart is unsafe. If no projects are processed, testStart will remain undefined, causing a runtime error. Consider initializing testStart to buildStart or adding a proper null check.

[Copilot]

Same issue as above - using non-null assertion on testStart is unsafe and could cause runtime errors if no projects are processed.

[Copilot]

Throwing a string instead of an Error object is not a best practice. Consider using throw new Error() for better error handling and stack traces.

[Copilot]

Throwing a string instead of an Error object is not a best practice. Consider using throw new Error() for better error handling and stack traces.

Suggested change

	throw `Project name "${config.name}" is already used. Please ensure all projects have unique names.
	Conflicting projects:
	${conflictProjects.map((p) => `- ${p.configFilePath || p.config.root}`).join('\n')}
	`;
	throw new Error(`Project name "${config.name}" is already used. Please ensure all projects have unique names.
	Conflicting projects:
	${conflictProjects.map((p) => `- ${p.configFilePath || p.config.root}`).join('\n')}`);

[njzydark]

Can a unified rstest.config be configured for the each project? If a single project directory has an rstest.config, will it be merged?

[9aoy]

Can a unified rstest.config be configured for the each project? If a single project directory has an rstest.config, will it be merged?

It seems that neither jest nor vitest will be merged by default, rstest will follow this behavior as well.