Merge branch 'main' into fix-9642-merge-reports-reporter-errors

Author: hi-ogawa

docs/.vitepress/sponsors.ts

@@ -6,14 +6,14 @@ export const sponsors: SponsorTier[] = [
     size: 'big',
     items: [
       {
-        name: 'NuxtLabs',
-        url: 'https://nuxtlabs.com',
-        img: '/nuxtlabs.svg',
+        name: 'Vercel',
+        url: 'https://vercel.com',
+        img: '/vercel.svg',
       },
       {
-        name: 'Bolt',
-        url: 'https://bolt.new',
-        img: '/bolt.svg',
+        name: 'Chromatic',
+        url: 'https://www.chromatic.com/?utm_source=vitest&utm_medium=sponsorship&utm_campaign=vitestSponsorship',
+        img: '/chromatic.svg',
       },
       {
         name: 'Zammad',
@@ -26,10 +26,11 @@ export const sponsors: SponsorTier[] = [
     tier: 'Platinum Sponsors',
     size: 'big',
     items: [
+
       {
-        name: 'Chromatic',
-        url: 'https://www.chromatic.com/?utm_source=vitest&utm_medium=sponsorship&utm_campaign=vitestSponsorship',
-        img: '/chromatic.svg',
+        name: 'Bolt',
+        url: 'https://bolt.new',
+        img: '/bolt.svg',
       },
     ],
   },

docs/api/advanced/vitest.md

@@ -349,7 +349,7 @@ This makes this method very slow, unless you disable isolation before collecting
 function cancelCurrentRun(reason: CancelReason): Promise<void>
 ```
 
-This method will gracefully cancel all ongoing tests. It will wait for started tests to finish running and will not run tests that were scheduled to run but haven't started yet.
+This method will gracefully cancel all ongoing tests. It will stop the on-going tests and will not run tests that were scheduled to run but haven't started yet.
 
 ## setGlobalTestNamePattern
 

docs/api/vi.md

@@ -1085,21 +1085,21 @@ import { vi } from 'vitest'
 vi.useFakeTimers()
 
 // Manual mode (default)
-vi.setTimerTickMode({ mode: 'manual' })
+vi.setTimerTickMode('manual')
 
 let i = 0
 setInterval(() => console.log(++i), 50)
 
 vi.advanceTimersByTime(150) // logs 1, 2, 3
 
 // nextTimerAsync mode
-vi.setTimerTickMode({ mode: 'nextTimerAsync' })
+vi.setTimerTickMode('nextTimerAsync')
 
 // Timers will advance automatically after each macrotask
 await new Promise(resolve => setTimeout(resolve, 150)) // logs 4, 5, 6
 
 // interval mode (default when 'fakeTimers.shouldAdvanceTime' is `true`)
-vi.setTimerTickMode({ mode: 'interval', interval: 50 })
+vi.setTimerTickMode('interval', 50)
 
 // Timers will advance automatically every 50ms
 await new Promise(resolve => setTimeout(resolve, 150)) // logs 7, 8, 9

docs/guide/improving-performance.md

@@ -77,6 +77,20 @@ export default defineConfig({
 
 You can limit the working directory when Vitest searches for files using [`test.dir`](/config/dir) option. This should make the search faster if you have unrelated folders and files in the root directory.
 
+## Caching Between Reruns
+
+In watch mode, Vitest caches all transformed files in memory, which makes reruns fast. However, this cache is discarded once the test run finishes. By enabling [`experimental.fsModuleCache`](/config/experimental#experimental-fsmodulecache), Vitest persists this cache to the file system so it can be reused across reruns.
+
+This improvement is most noticeable when rerunning a small number of tests that depend on a large module graph. For full test suites, parallelization already mitigates the cost because other tests populate the in-memory cache while earlier tests are still running. For example, running one test file with a huge module graph (>900 modules):
+
+```shell
+# the first run
+Duration  8.75s (transform 4.02s, setup 629ms, import 5.52s, tests 2.52s, environment 0ms, prepare 3ms)
+
+# the second run
+Duration  5.90s (transform 842ms, setup 543ms, import 2.35s, tests 2.94s, environment 0ms, prepare 3ms)
+```
+
 ## Pool
 
 By default Vitest runs tests in `pool: 'forks'`. While `'forks'` pool is better for compatibility issues ([hanging process](/guide/common-errors.html#failed-to-terminate-worker) and [segfaults](/guide/common-errors.html#segfaults-and-native-code-errors)), it may be slightly slower than `pool: 'threads'` in larger projects.

docs/guide/profiling-test-performance.md

@@ -112,20 +112,101 @@ test('formatter works', () => {
 
 <img src="/module-graph-barrel-file.png" alt="Vitest UI demonstrating barrel file issues" />
 
-To see how files are transformed, you can use `VITEST_DEBUG_DUMP` environment variable to write transformed files in the file system:
+To see how files are transformed, you can open the "Module Info" view in the UI:
+
+<img alt="The module info view for an inlined module" img-light src="/ui/light-module-info.png">
+<img alt="The module info view for an inlined module" img-dark src="/ui/dark-module-info.png">
+
+## File Import
+
+Some modules just take a long time to load. To identify which modules are the slowest, enable [`experimental.importDurations`](/config/experimental#experimental-importdurations) in your configuration:
+
+```ts [vitest.config.ts]
+import { defineConfig } from 'vitest/config'
+
+export default defineConfig({
+  test: {
+    experimental: {
+      importDurations: {
+        print: true,
+      },
+    },
+  },
+})
+```
+
+This will print a breakdown of the slowest imports after your tests finish:
+
+```bash
+Import Duration Breakdown (Top 10)
+
+Module                      Self     Total
+my-test.test.ts              5ms    620ms [████████████████████]
+date-fns/index.js          500ms    500ms [████████████████░░░░] # [!code error]
+src/utils/helpers.ts        10ms    120ms [████████░░░░░░░░░░░░]
+```
+
+You can also use `--experimental.importDurations.print` from the CLI without changing your configuration:
 
 ```bash
-$ VITEST_DEBUG_DUMP=true vitest --run
+vitest --experimental.importDurations.print
+```
+
+Once you've identified the slow modules, there are several strategies to speed up imports:
+
+### Use Specific Entry Points
+
+Many libraries ship multiple entry points. Importing the main entry point (which is often a [barrel file](https://vitejs.dev/guide/performance.html#avoid-barrel-files)) can pull in far more code than you need.
 
- RUN  v2.1.1 /x/vitest/examples/profiling
-...
+For example, `date-fns` re-exports hundreds of functions from its main entry point. Instead of importing from the top-level module, import directly from the specific function:
 
-$ ls .vitest-dump/
-_x_examples_profiling_global-setup_ts-1292904907.js
-_x_examples_profiling_test_prime-number_test_ts-1413378098.js
-_src_prime-number_ts-525172412.js
+```ts
+import { format } from 'date-fns' // [!code --]
+import { format } from 'date-fns/format' // [!code ++]
 ```
 
+### Use `resolve.alias` to Redirect Imports
+
+If a dependency doesn't provide granular entry points, or if third-party code imports the heavy entry point, you can use [`resolve.alias`](https://vite.dev/config/shared-options#resolve-alias) to redirect imports to a lighter alternative:
+
+```ts [vitest.config.ts]
+import { defineConfig } from 'vitest/config'
+
+export default defineConfig({
+  resolve: {
+    alias: [
+      {
+        find: /^date-fns$/,
+        replacement: join(dirname(require.resolve('date-fns/package.json')), 'index.cjs'),
+      },
+    ]
+  },
+})
+```
+
+### Use the Dependency Optimizer
+
+Vitest can bundle external libraries into a single file using [`deps.optimizer`](/config/deps#deps-optimizer), which reduces the overhead of importing packages with many internal modules:
+
+```ts [vitest.config.ts]
+import { defineConfig } from 'vitest/config'
+
+export default defineConfig({
+  test: {
+    deps: {
+      optimizer: {
+        ssr: {
+          enabled: true,
+          include: ['date-fns'],
+        },
+      },
+    },
+  },
+})
+```
+
+This is especially effective for UI libraries and packages with deep import trees. Use `optimizer.ssr` for `node`/`edge` environments and `optimizer.client` for `jsdom`/`happy-dom` environments.
+
 ## Code Coverage
 
 If code coverage generation is slow on your project you can use `DEBUG=vitest:coverage` environment variable to enable performance logging.

docs/public/nuxtlabs.svg

@@ -1,7 +1,7 @@
 {
   "name": "@vitest/monorepo",
   "type": "module",
-  "version": "4.1.0-beta.4",
+  "version": "4.1.0-beta.5",
   "private": true,
   "packageManager": "pnpm@10.30.2",
   "description": "Next generation testing framework powered by Vite",
@@ -35,6 +35,7 @@
     "ui:build": "vite build packages/ui",
     "ui:dev": "npm -C packages/ui run dev:client",
     "ui:test": "npm -C packages/ui run test:run",
+    "override-rolldown": "yq -i '.overrides.vite = \"npm:vite@beta\"' pnpm-workspace.yaml",
     "test:browser:webdriverio": "pnpm -C test/browser run test:webdriverio",
     "test:browser:playwright": "pnpm -C test/browser run test:playwright"
   },

docs/public/vercel.svg

@@ -1,7 +1,7 @@
 {
   "name": "@vitest/browser-playwright",
   "type": "module",
-  "version": "4.1.0-beta.4",
+  "version": "4.1.0-beta.5",
   "description": "Browser running for Vitest using playwright",
   "license": "MIT",
   "funding": "https://opencollective.com/vitest",

package.json

@@ -1,7 +1,7 @@
 {
   "name": "@vitest/browser-preview",
   "type": "module",
-  "version": "4.1.0-beta.4",
+  "version": "4.1.0-beta.5",
   "description": "Browser running for Vitest using your browser of choice",
   "license": "MIT",
   "funding": "https://opencollective.com/vitest",