Known issues with the Module Runner

[sheremet-va]

The current Vite SSR transform has some unaddressed, but known issues.

The getter approach has at least two known disadvantages:

• SSR transformed named imported functions don't work with debuggers "step-into" #18325
• The import language affect the benchmark result vitest-dev/vitest#6543

The debugger has to step into the getter when the export is accessed, which is inconvenient and confusing. (Another issue with the debugger not listed here is that "context variables" are listed as __vite_ssr_export__ instead of the actual imported names) This approach is also slow when user code accesses the variable - this is especially visible in the benchmarking feature of Vitest.

// slow and confusing during debug
Object.defineProperty(__vite_ssr_exports__, "createApp", { enumerable: true, configurable: true, get(){ return createApp }});

• Vite SSR Imports not loading classes correctly - constructors not loaded #14048

Module Runner is a CJS-style wrapper around the user code that supports top-level asynchronous execution. This, unfortunately, breaks circular imports because we don't have separate phases for linking and evaluation.

• Exporting redefined "Object" throws an error in SSR #15485

Users cannot define their own Object in the top level of their module because we expect to to be the global Object