feat: use module runner to import the config

[sheremet-va]

Description

Very rough idea to use the module runner instead of esbuild.build. Some advantages:

• no need to store a temporary file
• importer directory resolved correctly because files are not bundled into a single file (important for monorepos) when an external package is imported

Benchmarking the vitest.config.ts file in the root:

• 5-6ms to call resolveConfig to construct a simple resolved config (environment requires a config, we can construct a small one just for this environment since we control all private plugins)
• 0.1ms to init plugin container
• 23ms is runner.import
  • 2ms to run the code in AsyncFunction
  • 5ms to ssrTransform
  • 16ms to transform with esbuild

Overall the new approach takes ~28-32ms and the old one takes ~14-22ms, but resolving the config is not a hot path fortunetly. We can also shave off 5-6ms if we provide a dummy config

[sapphi-red]

Probably the test are failing because we support __dirname / __filename in ESM files as well.

[bluwy]

This looks similar to what Astro has been doing, which starts up the Vite server and ssrLoadModules the config file, which I had always find hacky 😅 But the module runner feels trimmed down and lightweight enough that this seems better.

Question: Does the module runner handle CJS config files well?

Probably the test are failing because we support __dirname / __filename in ESM files as well.

I'd honestly love if we start to not support them 😅 Separately from this PR, maybe we should start warning if we see them and suggest using import.meta.dirname or import.meta.filename instead if supported, or fiddling with import.meta.url.

[sheremet-va]

Probably the test are failing because we support __dirname / __filename in ESM files as well.

Good catch! We can inject it with a different evaluator.

[sheremet-va]

Good catch! We can inject it with a different evaluator.

Hm, module runner only supports ESM. Injecting __dirname and __filename is not enough 🤔

To support a CJS config, we need to reimplement most of vite-node's "mix cjs-esm" code. Unless we forbid CJS altogether 😄