feat(ssr): resolve externalized packages with `resolve.externalConditions` and add `module-sync` to default external condition #20409

sapphi-red · 2025-07-15T05:53:14Z

Description

~~built on top of #20279~~

This PR adds module-sync to the default resolve.externalCondition. module-sync condition is a condition introduced by Node when it supported require(ESM). This condition is used by Node when resolving both require and import when require(ESM) is enabled.

All Node versions supported by Vite supports require(ESM), so for ssrLoadModule and RunnableDevEnvironment, this change is fine. For other DevEnvironments that runs on non-Node runtime or Node version that doesn't support require(ESM), it would need to set resolve.externalCondition if they would like to align with the runtime's behavior. (It is not possible to set the conditions on our side as Vite doesn't know which runtime the environment will run on)

close #19201

packages/vite/src/node/ssr/index.ts

sapphi-red · 2025-07-17T02:55:26Z

vitest.config.e2e.ts

+  ssr: {
+    resolve: {
+      // FIXME: this is a bug in Vitest, resolving externalized modules should use externalConditions
+      conditions: ['node', 'module-sync'],
+    },
+  },


@hi-ogawa It seems Vitest uses resolve.conditions for both externalized files and no-externalized files. Is it possible to configure Vitest to only use module-sync for externalized files? (since module-sync should not be used for no-externalized files)

Yes, currently Vitest (technically due to vite-node) cannot use resolve.externalConditions for server external resolution and only uses resolve.conditions for everything. I haven't followed yet but @sheremet-va might know better what will change in vitest-dev/vitest#8208.

Is it possible to configure Vitest to only use module-sync for externalized files?

What's the desired goal for this diff specifically? Should tests pass without adding this but something failing?

I was expecting the tests to pass without specifying ssr.resolve.conditions: ['node', 'module-sync'].
playground/ssr-resolve/main.js is bundled to playground/ssr-resolve/dist/main.js and that file has import moduleSync from '@vitejs/test-module-sync'. That bundled file is imported at this line.

vite/playground/ssr-resolve/__tests__/ssr-resolve.spec.ts

Line 28 in 26b1b82

await expect(import(`${testDir}/dist/main.mjs`)).resolves.toBeTruthy()

Since @vitejs/test-module-sync is not processed by Vite / Vitest, I expected the resolver to use module-sync condition (as it's included in ssr.resolve.externalConditions). But it used the ssr.resolve.conditions and that does not include module-sync condition. So the resolution fails (pkg-module-sync only has module-sync condition).

No ideal but this is how it works currently. import(`${testDir}/dist/main.mjs`) is transformed and evaluated through vite-node and each package's external check is done after resolved through resolve.conditions (basically pluginContainer.resolveId) and it's not a same behavior as Vite SSR external. So, from what I know, this is not possible.

Is it possible to configure Vitest to only use module-sync for externalized files?

I'm not entirely sure the purpose of this test. Is this to confirm Vitest's behavior (with current PR change) works same as Vite SSR? Or do you want to test importing dist/main.js on a pure node runtime?

Vitest has its own externalization logic because Vite only supports externalizing in SSR, but we need the same behavior for JSDOM. We resolve the ID with pluginContainer.resolveId and check if it needs to be external

We cannot use externalConditions because we don't know if it's external yet

I see. Thanks for the answers.

Is this to confirm Vitest's behavior (with current PR change) works same as Vite SSR? Or do you want to test importing dist/main.js on a pure node runtime?

The main purpose of the test was to confirm the built file works in pure Node. But since the test was written in this way, I encountered this and wondered whether it's a way to configure Vitest to work more similar to Node on this aspect. I can run node command instead of this dynamic import here.

We cannot use externalConditions because we don't know if it's external yet

I think Vite has the same problem. Vite uses externalConditions when checking whether it needs to be external.
The reasoning is #14498 (comment)

sapphi-red · 2025-07-25T04:30:24Z

playground/ssr-resolve/main.js

 import pkgExportsEntry from '@vitejs/test-resolve-pkg-exports/entry'
 import deepFoo from '@vitejs/test-deep-import/foo'
-import deepBar from '@vitejs/test-deep-import/bar'
+// import deepBar from '@vitejs/test-deep-import/bar'


I commented out this test case as it wasn't working.
The output contains @vitejs/test-deep-import/bar as-is, but to make that work in Node, it needs to be rewritten to @vitejs/test-deep-import/utils/bar.js as Node does not read package.json for directory specifiers in ESM.

Does that mean this could be a breaking change if someone relied on the non-standard behavior before?

I'm ok with trying this out in a minor, but I think if we're not going to support this case here we can directly remove the test for it.

No, this code was not working without the change in this PR.
I changed the test code to run it in Node for #20409 (comment) and that caused the test to fail.
https://github.com/vitejs/vite/pull/20409/files#diff-859b1585f9b836443382acf98d7530dd7666ca2e0931021e82f745af51e233a3L26-R32

hi-ogawa · 2025-07-25T05:55:12Z

packages/vite/src/node/plugins/resolve.ts

+  const rawConditions = externalize
+    ? options.externalConditions
+    : options.conditions
+  const conditions = rawConditions.map((condition) => {


Is this a bug fix?

Yes.

If it is determined as external here,

vite/packages/vite/src/node/plugins/resolve.ts

Lines 348 to 352 in e7c3d47

const external =

options.externalize &&

options.isBuild &&

currentEnvironmentOptions.consumer === 'server' &&

shouldExternalize(this.environment, id, importer)

the resolution here should use externalConditions.

vite/packages/vite/src/node/plugins/resolve.ts

Line 383 in e7c3d47

(res = tryNodeResolve(id, importer, options, depsOptimizer, external))

Interesting, it's only for build? Might not be relevant to this PR specifically but curious what's the idea for options.isBuild check? Is this because Vite crawl imports by ourselves by import analysis resolve (and not resolve for external) during dev, but this is specifically for rollup?

If we have externalize flag in resolveExportsOrImports, then technically can we also pass this flag instead of swapping off options.conditions for fetchModule node resolve?

vite/packages/vite/src/node/ssr/fetchModule.ts

Lines 51 to 54 in 8033e5b

const resolved = tryNodeResolve(url, importer, {

mainFields: ['main'],

conditions: externalConditions,

externalConditions,

Interesting, it's only for build? Might not be relevant to this PR specifically but curious what's the idea for options.isBuild check? Is this because Vite crawl imports by ourselves by import analysis resolve (and not resolve for external) during dev, but this is specifically for rollup?

It is only for build. The purpose is to run this part of code:

vite/packages/vite/src/node/plugins/resolve.ts

Lines 771 to 787 in e7c3d47

let resolvedId = id

if (

deepMatch &&

!pkg.data.exports &&

path.extname(id) !== path.extname(resolved.id)

) {

// id date-fns/locale

// resolve.id ...date-fns/esm/locale/index.js

const index = resolved.id.indexOf(id)

if (index > -1) {

resolvedId = resolved.id.slice(index)

debug?.(

`[processResult] ${colors.cyan(id)} -> ${colors.dim(resolvedId)}`,

)

}

}

return { ...resolved, id: resolvedId, external: true }

In dev, this specifier rewrite is not needed because fetchModule handles that.

If we have externalize flag in resolveExportsOrImports, then technically can we also pass this flag instead of swapping off options.conditions for fetchModule node resolve?

No, we cannot do that. Because tryNodeResolve will return a non-absolute id when externalize is true (e.g. react/jsx-runtime).

Thanks for the reference 👍 As I understand, the latter part of processResult where it checks resolved.id is fairly an edge case, so previously using conditions instead of externalConditions wouldn't have made much difference.

I'm still digesting the history of that logic, but will follow up on that on my own.

hi-ogawa · 2025-07-28T05:32:02Z

packages/vite/src/node/plugins/resolve.ts

+  const rawConditions = externalize
+    ? options.externalConditions
+    : options.conditions
+  const conditions = rawConditions.map((condition) => {


Thanks for the reference 👍 As I understand, the latter part of processResult where it checks resolved.id is fairly an edge case, so previously using conditions instead of externalConditions wouldn't have made much difference.

I'm still digesting the history of that logic, but will follow up on that on my own.

bluwy

IIUC the PR also includes a bug fix for resolving externaled packages. I think it would be nice if it can be mentioned in the PR title too so it's tracked in the changelog in case it affects someone.

I'm a bit afraid that this could break for some people, so maybe something we need to watch out for after merging in case we should reconsider it.

sapphi-red · 2025-07-29T08:10:21Z

/ecosystem-ci run

pkg-pr-new · 2025-07-29T08:11:13Z

Open in StackBlitz

npm i https://pkg.pr.new/vite@20409

commit: e7c3d47

vite-ecosystem-ci · 2025-07-29T09:13:40Z

📝 Ran ecosystem CI on e7c3d47: Open

suite	result	latest scheduled
vike	✅ success	❌ failure
astro	❌ failure	❌ failure
waku	❌ failure	✅ success
vitest	❌ failure	❌ failure

✅ ladle, analogjs, marko, one, qwik, react-router, laravel, nuxt, quasar, sveltekit, storybook, rakkas, vite-environment-examples, unocss, vite-plugin-react, vite-plugin-svelte, vite-plugin-pwa, vite-plugin-cloudflare, vite-setup-catalogue, histoire, vite-plugin-vue, vuepress, vite-plugin-rsc, vitepress

sapphi-red · 2025-07-29T09:55:43Z

waku is failing with the main branch as well: https://github.com/vitejs/vite-ecosystem-ci/actions/runs/16592408110/job/46931036774

….externalConditions` (#5491) Port of vitejs/vite#20409

Andarist and others added 2 commits June 24, 2025 11:31

feat(exports): export defaultExternalConditions

3706eee

feat(ssr): add module-sync to default externalCondition

87d34b9

sapphi-red added feat: ssr p3-significant High priority enhancement (priority) labels Jul 15, 2025

wip

1e2fc8f

benmccann reviewed Jul 17, 2025

View reviewed changes

packages/vite/src/node/ssr/index.ts Outdated Show resolved Hide resolved

chore: update jsdoc comment

26b1b82

sapphi-red commented Jul 17, 2025

View reviewed changes

sapphi-red changed the title ~~feat(ssr): add module sync to default external condition~~ feat(ssr): add module-sync to default external condition Jul 23, 2025

sapphi-red added this to the 7.1 milestone Jul 25, 2025

sapphi-red added 3 commits July 25, 2025 12:47

chore: merge main

6d38029

test: use node command

7ad1b12

test: comment out failing test case that wasn't working

e7c3d47

sapphi-red commented Jul 25, 2025

View reviewed changes

sapphi-red marked this pull request as ready for review July 25, 2025 04:30

hi-ogawa reviewed Jul 25, 2025

View reviewed changes

hi-ogawa approved these changes Jul 28, 2025

View reviewed changes

bluwy approved these changes Jul 29, 2025

View reviewed changes

sapphi-red changed the title ~~feat(ssr): add module-sync to default external condition~~ feat(ssr): resolve external with resolve.externalConditions add module-sync to default external condition Jul 29, 2025

sapphi-red changed the title ~~feat(ssr): resolve external with resolve.externalConditions add module-sync to default external condition~~ feat(ssr): resolve externalized packages with resolve.externalConditions and add module-sync to default external condition Jul 29, 2025

vite-ecosystem-ci bot added the trigger: preview label Jul 29, 2025

This comment was marked as outdated.

Sign in to view

sapphi-red mentioned this pull request Jul 29, 2025

fix(plugin/vite-resolve): resolve externalized packages with resolve.externalConditions rolldown/rolldown#5491

Merged

sapphi-red merged commit c669c52 into vitejs:main Jul 29, 2025
20 checks passed

sapphi-red deleted the feat/ssr-add-module-sync-to-default-external-condition branch July 29, 2025 09:57

github-merge-queue bot pushed a commit to rolldown/rolldown that referenced this pull request Jul 30, 2025

fix(plugin/vite-resolve): resolve externalized packages with `resolve…

5d36578

….externalConditions` (#5491) Port of vitejs/vite#20409

	const external =
	options.externalize &&
	options.isBuild &&
	currentEnvironmentOptions.consumer === 'server' &&
	shouldExternalize(this.environment, id, importer)

	const resolved = tryNodeResolve(url, importer, {
	mainFields: ['main'],
	conditions: externalConditions,
	externalConditions,

	let resolvedId = id
	if (
	deepMatch &&
	!pkg.data.exports &&
	path.extname(id) !== path.extname(resolved.id)
	) {
	// id date-fns/locale
	// resolve.id ...date-fns/esm/locale/index.js
	const index = resolved.id.indexOf(id)
	if (index > -1) {
	resolvedId = resolved.id.slice(index)
	debug?.(
	`[processResult] ${colors.cyan(id)} -> ${colors.dim(resolvedId)}`,
	)
	}
	}
	return { ...resolved, id: resolvedId, external: true }

Uh oh!

feat(ssr): resolve externalized packages with resolve.externalConditions and add module-sync to default external condition #20409

feat(ssr): resolve externalized packages with resolve.externalConditions and add module-sync to default external condition #20409

Uh oh!

Conversation

sapphi-red commented Jul 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sapphi-red Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hi-ogawa Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sheremet-va Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sapphi-red Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bluwy left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sapphi-red commented Jul 29, 2025

Uh oh!

pkg-pr-new bot commented Jul 29, 2025

Uh oh!

This comment was marked as outdated.

vite-ecosystem-ci bot commented Jul 29, 2025

Uh oh!

sapphi-red commented Jul 29, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

feat(ssr): resolve externalized packages with `resolve.externalConditions` and add `module-sync` to default external condition #20409

feat(ssr): resolve externalized packages with `resolve.externalConditions` and add `module-sync` to default external condition #20409

sapphi-red commented Jul 15, 2025 •

edited

Loading

sapphi-red Jul 17, 2025 •

edited

Loading

hi-ogawa Jul 17, 2025 •

edited

Loading

sheremet-va Jul 17, 2025 •

edited

Loading

sapphi-red Jul 17, 2025 •

edited

Loading

bluwy left a comment •

edited

Loading