new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Vitest · Config reference · all subjects

config/pool

11 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

pool option type and default

The pool option has type 'threads' | 'forks' | 'vmThreads' | 'vmForks' with a default value of 'forks'. It can be set via CLI with --pool=threads.

threads pool mode

The 'threads' pool enables multi-threading. When using threads, process-related APIs such as process.chdir() are unavailable. Libraries written in native languages like Prisma, bcrypt, and canvas may have problems running in multiple threads and can encounter segfaults, in which case the 'forks' pool is recommended instead.

forks pool mode

The 'forks' pool is similar to 'threads' but uses child_process instead of worker_threads. Communication between tests and the main process is not as fast as with the 'threads' pool. Process-related APIs such as process.chdir() are available in the 'forks' pool.

vmThreads pool mode

The 'vmThreads' pool runs tests using VM context in a sandboxed environment within a threads pool. Tests run faster but the VM module is unstable when running ESM code. Tests will leak memory, so workers are restarted when they exceed vmMemoryLimit. Worker recycling is expensive in vmThreads because Node.js runs a full garbage collection before the thread can exit, using a small shared pool of background threads.

vmThreads require() ESM support

On Node.js 24.9 and later, require() of an ES module is supported inside vm pools, mirroring Node's own require(esm). Calling require() on an ES module whose graph contains top-level await throws ERR_REQUIRE_ASYNC_MODULE - use await import() for those files.

vmThreads sandbox globals issue

When running code in a sandbox with vmThreads, globals within native modules such as fs and path differ from the globals in the test environment. Error objects thrown by native modules reference a different Error constructor than the one used in the code, so instanceof checks fail.

vmThreads ES module caching issue

In vmThreads, importing ES modules caches them indefinitely, which introduces memory leaks if there are many contexts (test files). There is no API in Node.js that clears this cache.

vmThreads globals access performance

Accessing globals takes longer in a sandbox environment compared to a normal environment.

vmForks pool mode

The 'vmForks' pool is similar to 'vmThreads' but uses child_process instead of worker_threads. Communication between tests and the main process is not as fast as with vmThreads. Process-related APIs such as process.chdir() are available in vmForks. This pool has the same pitfalls listed in vmThreads.

vmForks worker recycling advantage

Unlike vmThreads, recycling a worker that exceeded vmMemoryLimit in vmForks only requires the child process to exit, making it much cheaper. On large test suites that recycle workers regularly, vmForks is usually noticeably faster than vmThreads even though its communication with the main process is slower.

vmMemoryLimit affects only vmForks and vmThreads pools

The vmMemoryLimit option only affects the vmForks and vmThreads pools, not other pool types.

Give your agent this brain