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

This PR also adds an inlineImport experimental helper that creates a temporary environment with a module runner to import a single file.

[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 😄

[pi0]

Maybe here we can expose a close callback that can free up mem?

[sheremet-va]

For now, I am just always closing the environment. I think if people want to use import files repeatedly, they can construct their own module runner. Or we can also expose something like createInlinedModuleRunner that creates the environment all by itself

[sheremet-va]

I added --bundleConfig=false option to the CLI; I am open to suggestions on how we should name it. Also need to add a note somewhere in the documentation 🤔

[bluwy]

Shouldn't using the module runner be opt-in instead? IIUC there's features like __filename and CJS that won't work properly if this is used by default.

For the option name, it would be nice if it's --configLoader runner perhaps, so that we could also introduce other options like "native" too (if we want that).

[sheremet-va]

It is opt-in, bundleConfig is true by default 😄

[bluwy]

Oh didn't notice that, I thought it was false by default. It feels a bit inverted to me to "disable bundleConfig" to "enable import with module runner" though 😅

[sheremet-va]

Oh didn't notice that, I thought it was false by default. It feels a bit inverted to me to "disable bundleConfig" to "enable import with module runner" though 😅

Yeah, I agree. I just couldn't come up with a good name. I like configLoader