feat: support full bundle mode in ssr#21626
Conversation
|
Very excited to see the beginnings of this! |
…he runner code to minimise copypaste
| // We need the proxy because the runtime MUST be ready before the first import is processed. | ||
| // Because `context['__rolldown_runtime__']` is passed down before the modules are executed as a function argument. |
There was a problem hiding this comment.
Would this part be simple if the runtime class was created on the module runner side?
I wonder if that's possible by setting implement: '' and calling new ViteDevRuntime here directly.
There was a problem hiding this comment.
Yes, it would be nice if we could somehow pass it down
There was a problem hiding this comment.
I think we have to have it in the environment to keep things simpler, actually. So that both client and ssr implementation don't diverge too much. The ViteDevRuntime could be defined in a different chunk and tracking it can become hard for no gain, really. Having a proxy and delayed initialization works fine, in my opinion
…undle-mode-in-ssr
…undle-mode-in-ssr
|
Both HMR and dynamic imports should work now. Unfortunately, if there is an external dependency in a dynamic import, it won't be loaded properly for now (this is a bug in rolldown) |
| createFullBundleRunnableDevEnvironment, | ||
| isFullBundleRunnableDevEnvironment, | ||
| // TODO: should have a unified FBM Dev Environment, not split between client and ssr | ||
| FullBundleRunnableDevEnvironment, |
There was a problem hiding this comment.
| FullBundleRunnableDevEnvironment, | |
| type FullBundleRunnableDevEnvironment, |
I guess it's ok not to expose the class value.
There was a problem hiding this comment.
I think it being an alternative to DevEnvironment which we do expose, makes it a requirement to expose this
| dynamicRelative: await import(nameRelative), | ||
| dynamicAbsolute: await import(nameAbsolute), | ||
| dynamicAbsoluteExtension: await import(nameAbsoluteExtension), | ||
| dynamicAbsoluteFull: await import( | ||
| (process.platform === 'win32' ? '/@fs/' : '') + absolutePath | ||
| ), | ||
| dynamicFileUrl: await import(fileUrl), |
There was a problem hiding this comment.
Are these the ones not working because of the bug in Rolldown?
| if (!ssrResult) { | ||
| throw new Error(`[vite] cannot apply ssr transform to '${url}'.`) | ||
| } | ||
| result.code = ssrResult.code |
There was a problem hiding this comment.
Do we need to update the sourcemap here?
There was a problem hiding this comment.
We probably should, but I am not sure how we update the source maps after HMR happens since we only get patches there
|
|
||
| it('exports is not modifiable', async ({ runner }) => { | ||
| it('exports is not modifiable', async ({ runner, skip, fullBundle }) => { | ||
| // TODO: fix in rolldown |
I am exploring how full bundle mode can be supported in SSR. At the moment the goal is to support
environments.ssr.runner.importandenvironment.fetchModule. Module graph,transformRequest,pluginContainerare out of scope of this PR, but they will be revisited later.Known quirks (to discuss)
runner.import(url)is not resolved withresolveIdlike it is done usually. Instead it accepts:rolldownOptions.input/(/entry-point.jsvs./entry-point.js)urlmust be an actual filename or a URL with the extension at the endimport.meta.url,import.meta.filenameandimport.meta.dirnamereference "would be" (or "virtual") files, these are the URLs that would exist if vite kept the bundle on the file system. Doing something likereadFileSync(import.meta.filename)will throw an error because the file does not exist on disk{ ourDir: './dist' }, the filename would be something like<root>/dist/asset/chunk-1.jsTo enable full bundle mode in SSR, add this to the config: