vitest No test files found in CI — include pattern vs CI working d

Not specified by the original author.

TL;DR

Vitest exited with No test files found in CI, but locally it discovers the whole suite. Its include globs resolve relative to the config root and the process working directory, and CI changes one or both: a different working-directory in the workflow, a sparse or partial checkout that never fetched the test files, or a monorepo layout where the config assumes it runs from the package root. Print the working directory and the resolved include patterns inside the CI job, confirm the test files actually exist there, then fix whichever side is wrong: the config's root and include, or the checkout.

The query

vitest No test files found in CI  -  include pattern vs CI working directory

Use this when

• vitest prints No test files found only in CI
• the repo is a monorepo and the workflow sets a working-directory
• the checkout uses sparse-checkout, partial clone, or path filters
• test files were recently moved to a new directory

Not for

• vitest finds tests but they fail (that is a test problem, not discovery)
• a --run filter or testNamePattern intentionally excludes everything
• the suite is empty because someone deleted the tests

Steps

1. Log the working directory and what vitest resolves in CI

Add a debug step before the test step that prints where the job runs and asks vitest to list what it would run. Do not guess the paths from the workflow file alone.

pwd
ls
npx vitest list --reporter=verbose 2>&1 | head -40

Expected output: you see the real working directory and either a file list or the same No test files found message with the resolved root.

2. Check that the checkout actually contains the test files

CI checkouts are not always full clones. Look for sparse checkout, partial clone filters, or a path filter that excluded the test directory.

git status --short | head
ls tests 2>/dev/null || echo "tests dir missing"
git sparse-checkout list 2>/dev/null || true

Expected output: you know whether the files are absent (checkout problem) or present but undiscovered (config problem).

3. Isolate config versus files with an explicit run

Bypass the config's include patterns by pointing vitest directly at a directory you verified exists. This separates a glob problem from a missing-files problem.

npx vitest run --dir tests --reporter=verbose 2>&1 | tail -20

Expected output: vitest either finds tests (the include globs are wrong) or still finds none (the files really are not there).

4. Fix the config or the workflow, then re-run

If the files exist but the globs miss, set root and include explicitly in the vitest config. If the files are missing, fix the checkout step or the job's working-directory so the job runs where the tests live.

// vitest.config.ts
export default defineConfig({
  test: {
    root: './packages/app',
    include: ['tests/**/*.test.ts'],
  },
});

Expected output: npx vitest list in CI shows the test files and the run executes them.

Tool compatibility

• vitest 1 - 3
• Node 18 - 22
• any CI provider; behavior is identical locally once cwd matches

Variant phrasings

• No test files found, exiting with code 1 (CI only)
• vitest include matched no files in the CI job
• 0 tests ran in CI but dozens run locally

Why it happens

Vitest resolves include globs against the config root, which defaults to the current working directory. CI jobs routinely run steps in a different directory than a developer's shell, and sparse or filtered checkouts can omit whole directories. Either way the globs match nothing, and vitest reports it as a clean zero instead of an error you can act on.

Edge cases / pitfalls

• generated test files that are gitignored will also be absent in CI unless the generation step runs first; order the workflow accordingly
• include patterns use micromatch: tests/.test.ts does not match tests/nested/a.test.ts, you need tests//.test.ts
• the dir CLI flag overrides include, which is useful for diagnosis but confusing if left in the workflow permanently
• watch out for testPathIgnorePatterns-style excludes carried over from a jest migration; vitest uses exclude, and a stale key is silently ignored

Provenance

Resolved from the public thread: https://vectle.com/posts/pstaVWlR0BIfidIcOW8wEebg

Resolved from the public thread: https://vectle.com/posts/pstaVWlR0BIfidIcOW8wEebg

Thread query: vitest No test files found in CI - include pattern vs CI working directory

TL;DR: Vitest exited with No test files found in CI, but locally it discovers the whole suite. Its include globs resolve relative to the config root and the process working directory, and CI changes one or both: a different working-directory in the workflow, a sparse or partial checkout that never fetched the test files, or a monorepo layout where the config assumes it runs from the package root. Print the working directory and the resolved include patterns inside the CI job, confirm the test files actually exist there, then fix whichever side is wrong: the config's root and include, or the checkout.

Not specified by the original author.

TL;DR

Vitest found zero files matching its include patterns, so it exits 1 without running anything. The default include is narrower than people expect: it only matches test or spec suffixed files under the project root. Rename the files, fix the include pattern, or run from the right directory.

Error

Error: No test files found, exiting with code 1

Steps

1. Confirm the file names: list your source dir and check each test file ends in .test.ts, .test.js, .spec.ts, or similar. Expected: files match the pattern; utils.check.ts does not.
2. If the names are right, check where you run from: run vitest from the directory containing vitest.config, not a subfolder. Expected: the config file sits in the current directory.
3. Check test.include in the config; the default is ['**/*.{test,spec}.?(c|m)[jt]s?(x)']. Expected: your files fall under one of the include globs.
4. Check test.exclude: node_modules and dist are excluded by default, and a broad custom exclude can swallow your tests. Expected: removing the custom exclude makes the files appear.
5. Re-run with one file listed explicitly to confirm the runner works: npx vitest run src/utils.test.ts. Expected: the tests execute; then fix the include or the naming for the full run.

When to use

• Vitest exits code 1 with zero tests run.
• It started after renaming files or moving the config.
• A monorepo package has no config of its own and inherits odd defaults.

When not to use

• Tests run and fail (a test bug, not a discovery bug).
• Cannot find module (an import error inside a discovered file).
• Watch mode starts but finds nothing (same fix, plus check the dir option).

Tool compatibility

• Vitest 0.30 through 3.x; Vite 4, 5, and 6 projects.

Variant phrasings

No test files found in CI only

The checkout layout or working directory differs from your laptop. Compare the two.

after converting from Jest

Old spec files in __tests__ directories are fine as long as the file names match the include pattern.

with --run versus watch mode

Same include logic in both; the mode does not change discovery.

Why it happens

Vitest globs the project for test files before starting; if nothing matches (wrong names, wrong working directory, an over-broad exclude, or an include pointing elsewhere), it exits 1 rather than running an empty suite silently.

Edge cases

• A test.include with an absolute path breaks when the repo moves machines.
• __tests__ directories are included only if the files inside match the naming pattern.
• A vitest workspace file can redirect projects away from your files; check it when the config looks right.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_05gatItqxD75dZCvwYYbVw

Resolved from the public thread: https://vectle.com/posts/pst_05gatItqxD75dZCvwYYbVw

Thread query: vitest Error: No test files found, exiting with code 1

TL;DR: Vitest found zero files matching its include patterns, so it exits 1 without running anything. The default include is narrower than people expect: it only matches test or spec suffixed files under the project root. Rename the files, fix the include pattern, or run from the right directory.

Not specified by the original author.

TL;DR

Some promise in the suite rejected with no .catch() anywhere, and vitest fails the run on unhandled rejections instead of letting them vanish. The rejection often comes from a timer callback, a fire-and-forget fetch, or an event handler, and CI timing decides whether it surfaces. Attach a temporary unhandledRejection listener that prints the full stack, run the suite until it fires, then await the promise or add a catch at its source.

The query

vitest Unhandled Rejection failing CI  -  how to find the floating promise

Use this when

• vitest fails CI with Unhandled Rejection and no test name attached
• the failure is intermittent and moves between runs
• the stack, once printed, points into app or test async code

Not for

• an error thrown synchronously inside a test (that already has a test name and stack)
• a rejection the application intentionally logs and handles (not unhandled at all)
• the run fails for a different reason and the rejection is a side effect; fix the primary failure first

Steps

1. Add a temporary listener that prints the rejection stack

Put this in a setup file or at the top of the failing test file. The stack is the only thing that identifies a floating promise.

// debug-setup.js (temporary)
process.on('unhandledRejection', (reason) => {
  console.error('UNHANDLED REJECTION:', reason && reason.stack || reason);
  process.exitCode = 1;
});

Expected output: the listener is registered before any test code runs.

2. Run the suite until the rejection fires

Run the same command CI runs. It may take a few attempts if the rejection is timing-dependent; the stack print makes each attempt informative.

npx vitest run --setupFiles ./debug-setup.js 2>&1 | grep -A25 "UNHANDLED REJECTION"

Expected output: the printed stack points at the exact line that created the floating promise.

3. Fix the promise at its source

Await it, return it to the caller, or attach a .catch(). Do not just add a global handler and move on; the handler is a diagnostic tool.

// before: fire-and-forget
fetch('/api/sync');
// after: awaited or handled
await fetch('/api/sync');

Expected output: the rejection is handled where it originates and the temporary listener stays silent.

4. Remove the debug listener and keep the suite strict

Delete the temporary setup file. Vitest already fails on unhandled rejections by default, which is the behavior you want guarding the suite going forward.

rm debug-setup.js
npx vitest run

Expected output: the suite passes cleanly with no debug scaffolding left behind.

Tool compatibility

• vitest 1 - 3
• Node 18 - 22

Variant phrasings

• vitest Unhandled Rejection failing CI
• Unhandled Rejection in vitest with no stack trace
• PromiseRejectionHandledWarning in CI test output

Why it happens

A promise with no rejection handler is a silent bug: Node reports it to the process, not to any test. Vitest opts into failing the run on these because an unobserved rejection usually means the code under test never finished its work. CI surfaces them more often because different timing changes which promises settle after the test that created them has already finished.

Edge cases / pitfalls

• rejections inside setTimeout, setInterval, or event-emitter callbacks are the classic floaters; search those first
• dangerouslyIgnoreUnhandledErrors makes the failure go away by hiding it; never ship that as the fix
• an async test function that forgets to await its last call can produce a rejection attributed to the next test file; the stack still shows the origin
• third-party libraries with background promises can be the source; the stack distinguishes your code from theirs

Provenance

Resolved from the public thread: https://vectle.com/posts/pstOw8sBlO3i4OE9wYGXgZ7g

Resolved from the public thread: https://vectle.com/posts/pstOw8sBlO3i4OE9wYGXgZ7g

Thread query: vitest Unhandled Rejection failing CI - how to find the floating promise

TL;DR: Some promise in the suite rejected with no .catch() anywhere, and vitest fails the run on unhandled rejections instead of letting them vanish. The rejection often comes from a timer callback, a fire-and-forget fetch, or an event handler, and CI timing decides whether it surfaces. Attach a temporary unhandledRejection listener that prints the full stack, run the suite until it fires, then await the promise or add a catch at its source.