[cryptodev-2s]

Explanation

The shared Vitest config only includes src/**/*.test.ts, but Jest's default testMatch picks up test files anywhere in a package. Seven packages still on Jest keep tests outside src/, almost all of them in a tests/ directory, so migrating any of them would silently stop running those files while the suite still reported green.

References

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
  • Not applicable, test only change. Carries the no-changelog label.
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them
  • None.

---

Note

Low Risk
Test-runner configuration only; no runtime or API behavior changes.

Overview
Expands the shared package Vitest include glob so suites match Jest-style layouts: tests under src/ still run, and tests/**/*.test.ts is picked up without per-package overrides.

This avoids silently dropping large tests/ suites when migrating packages from Jest (e.g. network-controller), where most coverage can live outside src/. Packages already on Vitest with only src/ tests are unchanged; packages that intentionally ignore tests/ (e.g. wallet-cli) can still exclude that path locally when they migrate.

^{Reviewed by Cursor Bugbot for commit 2799423. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cryptodev-2s]

we could also just use configDefaults from https://vitest.dev/config/include

[mcmire]

We could, but currently we are following the MetaMask unit testing guidelines, which say that unit tests are located next to source files.

[cryptodev-2s]

I see thanks, but we still need this PR because of some tests that are still under tests

[mcmire]

I was going to suggest that we override this at the package-level vitest.config.packages.js. But I see now that we're just trying to replicate the existing Jest config. So this seems fine.