New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Generalized ssrLoadModule()
#4081
Comments
Forgot to link for Snowpack mention:
|
Just a note that I found a sort-of workaround for Even with such caveats in this workaround, it should be obvious that the current problems are not inherent to vite's design and can't be considered out of scope for the project either. |
I also found a workaround for build time, where I just create a dev server to use |
Hi @wlib. I wonder if this feature request still needed?
Transforming files in build mode should use normal Vite plugins as you have more control of how the final build output/chunks comes out. I don't quite understand how I think ultimately the ecosystem has grown a lot recently on this area, especially with Vitest spearheading the usage of Vite's SSR transforms in NodeJS. For example, vite-node is used to power Vitest by leveraging Vite as a Node runtime. |
For reference, see also the use of vite-node in Nuxt nuxt/framework#2795 |
Closing due to lack of response, but I think the above comment covers what this issue is proposing. |
Clear and concise description of the problem
Vite uses html files as entry points at both dev and build time. I created a plugin that abstracts this by generating the html content with an esm module before vite internally transforms it. During dev, is relies on
ViteDevServer.ssrLoadModule()
as if it was a form of dynamicimport()
but with vite transforms and fast invalidation.But there are two major problems that get in the way of many important plugin use cases:
ssrLoadModule()
was made to load "client-type" code in node, failing to load anything likeimport fs from "fs/promises"
(within the normal vite dev configuration, at least).require()
will not work as a substitute forssrLoadModule()
.ssrLoadModule()
relies on aViteDevServer
, meaning that there is no way to apply its value (of applying vite transforms to e.g.(j|t)sx?
modules) during vite's build mode.This has forced my plugin into a corner of only being able to work with vanilla node during build time and not being allowed to import any node api's (even dynamically within an
if (false)
block!) during dev time. This makes my "lowest common denominator" allowed code almost useless, for arbitrary reasons.Suggested solution
Snowpack has already declared the intention of moving towards fully generalized node SSR, which is exactly what we need. The best solution is basically to integrate what my plugin was aiming to implement directly into vite (abstract index.html as the entry point). But the easiest solution is to simply generalize
ssrLoadModule()
into a version that:import()
of node esmViteDevServer
, enabling its usage within e.g. a build plugin'sload()
hook just as easily as in dev server middlewareAlternative
I hacked together a vite-incompatible function that simply built a temporary node esm file out of my prerendering code (including JSX) using esbuild and
import()
ed that file asfile:/temporarily/built/module.mjs?cache-buster=Math.random()
. It worked exactly how I expected as a proof of concept, with the only issues being efficiency for caching/invalidation (vite's module graph is valuable here) and that it was incompatible with vite's plugins (I had to hack thejsxInject
, any variabledefine
's, and had no automatic path rebasing).Obviously, a vite-native version would be far more streamlined and allow for many more useful plugin applications.
Additional context
No response
Validations
The text was updated successfully, but these errors were encountered: