-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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
feat(ssr): support for ssr.resolve.conditions and ssr.resolve.externalConditions options #14498
Conversation
Signed-off-by: Marc MacLeod <847542+marbemac@users.noreply.github.com>
Signed-off-by: Marc MacLeod <847542+marbemac@users.noreply.github.com>
Signed-off-by: Marc MacLeod <847542+marbemac@users.noreply.github.com>
const ssrConditions = | ||
resolveOptions.ssrConfig?.resolve?.conditions || | ||
resolveOptions.conditions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maintains current behavior if the new ssr.resolve.conditions field is not set - backwards compatible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! Thank you!
You can ignore the CI failure on Windows. It's caused by a bug in Node.
targetWeb, | ||
undefined, | ||
true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
targetWeb, | |
undefined, | |
true, | |
false, | |
undefined, | |
true, |
Because this part imitates Node and Node's resolver works like targetWeb=false
, this needs to be false
.
If we run this part with true
, the same code won't run after build because of that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, but afaik a main use case for ssr.target = 'webworker'
is for when the end user is planning to run in non-node runtimes (cloudflare, deno, bun, etc). This is how I've been using it at least - for example when using ssrLoadModule
in dev to load a file that imports renderToReadableStream
from react-dom
.
Although I suppose the end user can now achieve this same result by explicitly listing the relevant conditions in ssr.resolve
- the inconsistency between how dev server pipeline and build pipeline use ssr.target just felt a little weird.
Since there's another way to achieve the desired result via the new ssr.resolve options, I can change it back to false, just please confirm with a 👍 when you have a sec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, but afaik a main use case for
ssr.target = 'webworker'
is for when the end user is planning to run in non-node runtimes (cloudflare, deno, bun, etc).
If a user is going to create a bundle for non-node runtimes, we expect them to set ssr.noExternal: true
.
https://vitejs.dev/guide/ssr.html#ssr-bundle
This is because it doesn't make sense to externalize any modules in that case. (Bare import specifiers won't work in those environments because those environments doesn't support node_modules
resolutions.)
If the module is not externalized, ssr.target = 'webworker'
would set the targetWeb
for vite:resolve plugin and that would resolve the import instead of ssrLoadModule
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, but I still think there are some rough edges when trying to use vite createServer + ssrLoadModule to create a nice local dev server experience (in conjunction w actually running dev server in non node runtimes like bun, or when wanting to better represent the final build target during local dev when that build target is non-node like cloudflare). BUT I think best as a separate discussion, the adjustments in this PR make it possible to cover everything :).
I reverted the targetWeb change - thanks for the review!
Signed-off-by: Marc MacLeod <847542+marbemac@users.noreply.github.com>
Signed-off-by: Marc MacLeod <847542+marbemac@users.noreply.github.com>
@sapphi-red should I add some notes to |
It would be nice if you add it. Also in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice tests! Adding the docs would be a plus too.
72c0e5c
@sapphi-red @bluwy alrighty, I took a crack at some docs. There were two styles of links in the docs (relative file path |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💚
Just want to ask when will this feature be released? This seems to be the key blocker for framework related to react server component. |
We don't usually backport features to v4, so this will come in v5. I can cut another beta for it today, but for stable that will come sometime between mid-late October. |
Redwood (and I) would love it if you could make an exception and back-port this to v4 🙏 |
…lConditions options (#14498)
@Tobbe you don't need to be ESM-only to use Vite 5, unless you're using the |
@bluwy we use |
Description
fixes #14496
Related PRs: #14417 #13487
Currently the vite dev server (and thus
ssrLoadModule
) do not respectresolve.conditions
, and target node even whenssr.target
iswebworker
.This PR introduces a new
ssr.resolve
option to configure how internal and external imports are resolved during SSR.I attempted to follow the recommended behavior described in the comments of #13487.
I didn't update any documentation - can do that if there's a good chance this change will be accepted.
What is the purpose of this pull request?
Before submitting the PR, please make sure you do the following
fixes #123
).