aka bring all Jest (V8) bugs into Vitest

The idea is to have a separate pool that will spawn workers with tinypool, but they will not be isolated. Isolation is introduced by vm.createContext inside the worker. For this, we need to implement our own import handling. I think we should keep our __vitest_ssr_import__ because it is the only way to support both ESM/CJS in the same file in wrongly bundled dependencies.

This is an optional pool! You need to opt-in to use it:

• via CLI argument: --experimental-vm-threads (this will throw an error, if you use --threads or --browser at the same time)

• via config option:

  export default {
    test: {
      experimentalVmThreads: true,
    }
  }

• run only a subset of files using this pool with poolMatchGlob

  export default {
    test: {
      threads: true,
      // all test files will be running like they did before,
      // except for the tests in "fast-leaking-tests" directory 
      poolMatchGlob: [
        ['**/fast-leaking-tests/*.spec.ts', 'experimentalVmThreads'],
      ]
    }
  }

You also cannot disable isolation when using experimentalVm, because this doesn't make sense with this pool. If you don't need isolation, use threads or child_process directly.

vm has a notable memory leak problem, so we are also introducing experimentalVmWorkerMemoryLimit option (works like Jest's workerIdleMemoryLimit to destroy the worker before it reaches this point. It is set to max_heap/number_of_workers by default. You might have better performance if you tweak this value manually.

--experimental-vm-child-process (experimentalVmChildProcess) will be implemented in a separate PR.

Pros:

• Tests go brrrrr (fast)

Cons:

• Vm is not very good with ESM so this introduces a ton of complexity
• We will have this fan-favorite bug: Jest globals differ from Node globals jestjs/jest#2549
• And this one: Memory Leak on ridiculously simple repo jestjs/jest#7874
• Also this bug: Improve performance of accessing globals in scripts running in vm modules nodejs/node#31658
• Basically, all of these issues are now also our issues: Roadmap for stabilization of vm modules nodejs/node#37648

Breaking changes:

• the environment is now loaded via the native Node.js mechanism, it should be transformed before the file is passed down to Vitest
• all environments always require transformMode (web or ssr). If transform mode is not specified, it will throw an error
• "VitestExecutor" is moved from "vitest/node" to "vitest/execute" entry point