Skip to content
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

Merged
merged 8 commits into from Oct 5, 2023
Merged

feat(ssr): support for ssr.resolve.conditions and ssr.resolve.externalConditions options #14498

merged 8 commits into from Oct 5, 2023

Conversation

marbemac
Copy link
Contributor

@marbemac marbemac commented Sep 28, 2023

Description

fixes #14496

Related PRs: #14417 #13487

Currently the vite dev server (and thus ssrLoadModule) do not respect resolve.conditions, and target node even when ssr.target is webworker.

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?

  • Bug fix
  • New Feature
  • Documentation update
  • Other

Before submitting the PR, please make sure you do the following

  • Read the Contributing Guidelines.
  • Read the Pull Request Guidelines and follow the PR Title Convention.
  • Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
  • Ideally, include relevant tests that fail without this PR but pass with it.

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>
@marbemac marbemac changed the title fix(ssr): respect resolve.conditions when ssr.target is webworker feat(ssr): support for ssr.resolve.conditions and ssr.resolve.externalConditions options Sep 29, 2023
Comment on lines +178 to +180
const ssrConditions =
resolveOptions.ssrConfig?.resolve?.conditions ||
resolveOptions.conditions
Copy link
Contributor Author

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.

packages/vite/src/node/ssr/ssrExternal.ts Outdated Show resolved Hide resolved
@sapphi-red sapphi-red added p3-downstream-blocker Blocking the downstream ecosystem to work properly (priority) feat: ssr labels Sep 30, 2023
Copy link
Member

@sapphi-red sapphi-red left a 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.

packages/vite/src/node/ssr/ssrExternal.ts Outdated Show resolved Hide resolved
Comment on lines 289 to 291
targetWeb,
undefined,
true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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!

playground/ssr-conditions/src/direct-load.js Outdated Show resolved Hide resolved
Signed-off-by: Marc MacLeod <847542+marbemac@users.noreply.github.com>
Signed-off-by: Marc MacLeod <847542+marbemac@users.noreply.github.com>
@marbemac
Copy link
Contributor Author

marbemac commented Oct 2, 2023

@sapphi-red should I add some notes to docs/guide/ssr.md outlining the new ssr.resolve options, or are you/somebody else going to tackle the docs later?

@sapphi-red
Copy link
Member

It would be nice if you add it. Also in /docs/config/ssr-options.md. But I can add it later too.

sapphi-red
sapphi-red previously approved these changes Oct 3, 2023
patak-dev
patak-dev previously approved these changes Oct 3, 2023
bluwy
bluwy previously approved these changes Oct 3, 2023
Copy link
Member

@bluwy bluwy left a 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.

Signed-off-by: Marc MacLeod <847542+marbemac@users.noreply.github.com>
@marbemac marbemac dismissed stale reviews from bluwy, patak-dev, and sapphi-red via 72c0e5c October 3, 2023 15:45
@marbemac
Copy link
Contributor Author

marbemac commented Oct 3, 2023

@sapphi-red @bluwy alrighty, I took a crack at some docs. There were two styles of links in the docs (relative file path .md style links, and what look to be absolute URLs) - I chose relative file paths. Let me know if I missed anything!

Signed-off-by: Marc MacLeod <847542+marbemac@users.noreply.github.com>
sapphi-red
sapphi-red previously approved these changes Oct 4, 2023
Copy link
Member

@sapphi-red sapphi-red left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💚

docs/guide/ssr.md Outdated Show resolved Hide resolved
@bluwy bluwy merged commit d0afc39 into vitejs:main Oct 5, 2023
10 checks passed
@hyf0
Copy link
Contributor

hyf0 commented Oct 8, 2023

Just want to ask when will this feature be released? This seems to be the key blocker for framework related to react server component.

@bluwy
Copy link
Member

bluwy commented Oct 9, 2023

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.

@Tobbe
Copy link

Tobbe commented Oct 17, 2023

Redwood (and I) would love it if you could make an exception and back-port this to v4 🙏
We're not ready to upgrade to Vite v5 because we're not ESM-only ready just yet (working on it though!)

@bluwy
Copy link
Member

bluwy commented Oct 17, 2023

@Tobbe you don't need to be ESM-only to use Vite 5, unless you're using the ssr.format option? Using the CJS node API will still work albeit with the warning message that can be suppressed if really needed.

@Tobbe
Copy link

Tobbe commented Oct 17, 2023

@bluwy we use legacy.buildSsrCjsExternalHeuristics: true

patak-dev added a commit that referenced this pull request Oct 18, 2023
…nditions (#14498) (#14668)

Co-authored-by: Marc MacLeod <marbemac@gmail.com>
@patak-dev
Copy link
Member

@Tobbe @nksaraf @hyf0, we discussed with @bluwy and backported this PR (together with a few other minor features) and released vite 4.5.0 with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat: ssr p3-downstream-blocker Blocking the downstream ecosystem to work properly (priority)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

resolve conditions not respected when running the dev server / ssrLoadModule
6 participants