[leaysgur]

resolveConfig({ configFile }, 'build') uses process.cwd() for an unset or relative root. In editors with multiple workspace folders, plugins can therefore load files from another project.

This PR exports resolveConfigFromFile(configFile, options?) from vite-plus for ESM and CommonJS. Its default rootBase is the config file's parent directory. With an absolute configFile, default root resolution is independent of process.cwd(). Callers can pass { rootBase: projectRoot } when the config directory differs from the project directory.

Assume process.cwd() is /work/editor and configFile is /repo/config/vite.config.ts. These examples have no plugin changes to root or symbolic links.

Config root	Existing resolveConfig({ configFile }, 'build')	resolveConfigFromFile(configFile)	With { rootBase: '/repo' }
Unset, undefined, or ''	/work/editor	/repo/config	/repo
'app'	/work/editor/app	/repo/config/app	/repo/app
'../shared'	/work/shared	/repo/shared	/shared
'/srv/site'	/srv/site	/srv/site	/srv/site

An internal core option applies the selected base before plugin apply and config hooks. The helper preserves environment initialization, plugin hooks, and configuration metadata. It skips lazyPlugins factories during metadata reads. Relative configFile and explicit rootBase paths resolve from process.cwd(). The helper does not change the process cwd.

Existing resolveConfig() calls keep their behavior. The CLI resolver retains its inline root: cwd, including parent configs found through traverseUp. Oxlint and Oxfmt adoption requires a separate integration change. Each caller can choose the new helper and an explicit project base when needed; this choice is not restricted to LSP.

Refs: #3217

[cloudflare-workers-and-pages]

🚀 Deploying Preview to Cloudflare 🚀

Preview URL: https://vp-resolve-config-root-viteplus-dev.voidzero-docs.workers.dev (commit 5216e3e)

This URL reflects your latest Preview deployment

Preview Deployments by commit

Status	Deployment URL	Commit	Updated (UTC)	See this deployment's details
Build: Success ✅ Deployment: Success ✅ View logs ↗	https://23e55262-viteplus-dev.voidzero-docs.workers.dev	5216e3e	2026-10-28T04:48:04.003Z	Visit the dashboard ↗
Build: Success ✅ Deployment: Success ✅ View logs ↗	https://efa4d76e-viteplus-dev.voidzero-docs.workers.dev	7e71e52	2026-10-28T04:22:26.704Z	Visit the dashboard ↗
Build: Success ✅ Deployment: Success ✅ View logs ↗	https://3b774f59-viteplus-dev.voidzero-docs.workers.dev	b89078a	2026-10-28T01:38:42.555Z	Visit the dashboard ↗
Build: Success ✅ Deployment: Success ✅ View logs ↗	https://6fd6d0cb-viteplus-dev.voidzero-docs.workers.dev	38daf78	2026-10-27T23:45:38.444Z	Visit the dashboard ↗
Build: Success ✅ Deployment: Success ✅ View logs ↗	https://c5193d44-viteplus-dev.voidzero-docs.workers.dev	eea399d	2026-10-27T15:04:50.529Z	Visit the dashboard ↗
Build: Success ✅ Deployment: Success ✅ View logs ↗	https://37c65ef0-viteplus-dev.voidzero-docs.workers.dev	68ba917	2026-10-27T14:37:56.975Z	Visit the dashboard ↗
Build: Success ✅ Deployment: Success ✅ View logs ↗	https://1d46660d-viteplus-dev.voidzero-docs.workers.dev	d1b39c6	2026-10-27T09:05:17.559Z	Visit the dashboard ↗
Build: Success ✅ Deployment: Success ✅ View logs ↗	https://2493be01-viteplus-dev.voidzero-docs.workers.dev	4bb4b4a	2026-10-27T07:58:25.982Z	Visit the dashboard ↗
Build: Success ✅ Deployment: Success ✅ View logs ↗	https://8c3266f9-viteplus-dev.voidzero-docs.workers.dev	cd28972	2026-10-27T07:44:00.852Z	Visit the dashboard ↗
Build: Success ✅ Deployment: Success ✅ View logs ↗	https://73511175-viteplus-dev.voidzero-docs.workers.dev	7aad0d6	2026-10-27T07:39:30.581Z	Visit the dashboard ↗

View all previews: View all previews ↗

[github-actions]

✅ Staging deployment successful!

Preview: https://viteplus-staging.void.app/
Commit: 5216e3e

[leaysgur]

@fengmk2 Thanks for confirmation (and also testing?)!

My concern was the (just AI-generated) code; rather than re-implementing a similar mechanism, I was wondering whether there might actually be existing APIs or features available.

In this PR, I've made a few adjustments to the original proposal, and I'd appreciate it if you could review it.

[fengmk2]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-27T05:38:37.361412Z	ba6364a	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. You're on a roll.

Reviewed commit: ba6364a057

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

Preview binary sizes (eea399d)

Compared with the latest stable release, v1.4.0. Preview build.
Each row measures one binary. Negative changes mean a smaller preview binary.

Binary	Latest release	Preview	Change
vp (macOS ARM64)	5.38 MiB	5.39 MiB	+16.36 KiB (+0.30%)
NAPI (macOS ARM64)	42.20 MiB	42.25 MiB	+48.41 KiB (+0.11%)
vp (macOS x64)	6.82 MiB	6.84 MiB	+28.13 KiB (+0.40%)
NAPI (macOS x64)	47.34 MiB	47.39 MiB	+56.09 KiB (+0.12%)
vp (Linux ARM64 GNU)	6.81 MiB	6.84 MiB	+24.00 KiB (+0.34%)
NAPI (Linux ARM64 GNU)	31.44 MiB	31.47 MiB	+35.25 KiB (+0.11%)
vp (Linux ARM64 musl)	6.88 MiB	6.92 MiB	+32.20 KiB (+0.46%)
NAPI (Linux ARM64 musl)	30.67 MiB	30.69 MiB	+22.81 KiB (+0.07%)
vp (Linux x64 GNU)	8.22 MiB	8.26 MiB	+36.00 KiB (+0.43%)
NAPI (Linux x64 GNU)	35.45 MiB	35.51 MiB	+55.31 KiB (+0.15%)
vp (Linux x64 musl)	8.29 MiB	8.33 MiB	+36.24 KiB (+0.43%)
NAPI (Linux x64 musl)	34.43 MiB	34.46 MiB	+25.88 KiB (+0.07%)
vp (Windows x64)	6.09 MiB	6.13 MiB	+32.50 KiB (+0.52%)
NAPI (Windows x64)	31.16 MiB	31.18 MiB	+26.50 KiB (+0.08%)
Trampoline (Windows x64)	13.00 KiB	13.00 KiB	0 B (0.00%)
Installer (Windows x64)	4.67 MiB	4.68 MiB	+3.00 KiB (+0.06%)
vp (Windows ARM64)	5.33 MiB	5.35 MiB	+24.00 KiB (+0.44%)
NAPI (Windows ARM64)	27.57 MiB	27.59 MiB	+21.50 KiB (+0.08%)
Trampoline (Windows ARM64)	13.00 KiB	13.00 KiB	0 B (0.00%)
Installer (Windows ARM64)	3.85 MiB	3.85 MiB	+2.50 KiB (+0.06%)

gzip -9 sizes

Binary	Latest release	Preview	Change
vp (macOS ARM64)	3.20 MiB	3.21 MiB	+12.27 KiB (+0.37%)
NAPI (macOS ARM64)	18.25 MiB	18.27 MiB	+19.48 KiB (+0.10%)
vp (macOS x64)	3.38 MiB	3.39 MiB	+15.57 KiB (+0.45%)
NAPI (macOS x64)	19.44 MiB	19.47 MiB	+29.28 KiB (+0.15%)
vp (Linux ARM64 GNU)	3.69 MiB	3.71 MiB	+15.04 KiB (+0.40%)
NAPI (Linux ARM64 GNU)	13.31 MiB	13.33 MiB	+18.13 KiB (+0.13%)
vp (Linux ARM64 musl)	3.71 MiB	3.73 MiB	+16.30 KiB (+0.43%)
NAPI (Linux ARM64 musl)	13.01 MiB	13.02 MiB	+12.79 KiB (+0.10%)
vp (Linux x64 GNU)	3.76 MiB	3.77 MiB	+15.72 KiB (+0.41%)
NAPI (Linux x64 GNU)	14.12 MiB	14.14 MiB	+20.46 KiB (+0.14%)
vp (Linux x64 musl)	3.78 MiB	3.80 MiB	+15.27 KiB (+0.39%)
NAPI (Linux x64 musl)	13.66 MiB	13.67 MiB	+11.55 KiB (+0.08%)
vp (Windows x64)	2.82 MiB	2.83 MiB	+11.43 KiB (+0.40%)
NAPI (Windows x64)	12.69 MiB	12.71 MiB	+16.47 KiB (+0.13%)
Trampoline (Windows x64)	7.14 KiB	7.14 KiB	-1 B (-0.01%)
Installer (Windows x64)	2.24 MiB	2.24 MiB	+551 B (+0.02%)
vp (Windows ARM64)	2.69 MiB	2.70 MiB	+9.32 KiB (+0.34%)
NAPI (Windows ARM64)	12.05 MiB	12.06 MiB	+12.73 KiB (+0.10%)
Trampoline (Windows ARM64)	6.93 KiB	6.93 KiB	-1 B (-0.01%)
Installer (Windows ARM64)	2.14 MiB	2.14 MiB	+306 B (+0.01%)

Raw sizes are uncompressed file sizes. gzip sizes recompress each binary at level 9; they are not package or download archive sizes.
The baseline uses published release files, including NAPI packages from npm at the same version. Build versions and toolchains can affect the difference.

[github-actions]

Registry bridge build (eea399d)

This commit build is published to the registry bridge, which serves these as ordinary npm versions (every other package proxies to npmjs):

Package	Version
vite-plus	0.0.0-commit.eea399da26baaf2c65c81af11da948f583ab23cb
@voidzero-dev/vite-plus-core	0.0.0-commit.eea399da26baaf2c65c81af11da948f583ab23cb
create-vite-plus	0.0.0-commit.eea399da26baaf2c65c81af11da948f583ab23cb

Install the Vite+ CLI built from this commit, then migrate a project:

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/voidzero-dev/vite-plus/eea399da26baaf2c65c81af11da948f583ab23cb/packages/cli/install.sh | VP_PR_VERSION=3249 VP_LEGACY_INSTALLER_URL=https://raw.githubusercontent.com/voidzero-dev/vite-plus/eea399da26baaf2c65c81af11da948f583ab23cb/packages/cli/install-legacy.sh bash

# Windows (PowerShell)
$env:VP_PR_VERSION="3249"; $env:VP_LEGACY_INSTALLER_URL="https://raw.githubusercontent.com/voidzero-dev/vite-plus/eea399da26baaf2c65c81af11da948f583ab23cb/packages/cli/install-legacy.ps1"; irm https://raw.githubusercontent.com/voidzero-dev/vite-plus/eea399da26baaf2c65c81af11da948f583ab23cb/packages/cli/install.ps1 | iex

Or download the standalone Windows installer built from this commit:

Architecture	Installer
x64	vp-setup-x86_64-pc-windows-msvc.exe
Arm64	vp-setup-aarch64-pc-windows-msvc.exe

GitHub requires you to sign in and downloads each installer as a ZIP artifact. Extract vp-setup.exe, then run it against this preview build:

.\vp-setup.exe --version "0.0.0-commit.eea399da26baaf2c65c81af11da948f583ab23cb" --registry "https://registry-bridge.viteplus.dev/"

After installing, upgrade the current project's vite-plus to this test build with:

vp migrate

Or create a new project from this commit without installing the CLI:

export npm_config_registry=https://registry-bridge.viteplus.dev/ pnpm_config_registry=https://registry-bridge.viteplus.dev/
pnpm create vite-plus@0.0.0-commit.eea399da26baaf2c65c81af11da948f583ab23cb # or: npm create vite-plus@0.0.0-commit.eea399da26baaf2c65c81af11da948f583ab23cb

$env:npm_config_registry="https://registry-bridge.viteplus.dev/"; $env:pnpm_config_registry="https://registry-bridge.viteplus.dev/"
pnpm create vite-plus@0.0.0-commit.eea399da26baaf2c65c81af11da948f583ab23cb # or: npm create vite-plus@0.0.0-commit.eea399da26baaf2c65c81af11da948f583ab23cb

pnpm 11+ reads pnpm_config_registry, npm and older pnpm read npm_config_registry. The new project pins this build, so keep the registry set for later installs, or configure it as below.

Or point your package manager at the bridge registry https://registry-bridge.viteplus.dev/:

Package manager	Registry config
npm / pnpm / Bun	.npmrc: registry=https://registry-bridge.viteplus.dev/
Yarn (v2+)	.yarnrc.yml: npmRegistryServer: "https://registry-bridge.viteplus.dev/"

Then pin the build (vite aliases to vite-plus-core; pnpm can use a catalog, npm an overrides entry):

{
  "devDependencies": {
    "vite-plus": "0.0.0-commit.eea399da26baaf2c65c81af11da948f583ab23cb",
    "vite": "npm:@voidzero-dev/vite-plus-core@0.0.0-commit.eea399da26baaf2c65c81af11da948f583ab23cb"
  }
}

[github-actions]

🐳 Docker preview image

Built from this PR's registry bridge build:

Image	Compressed size
ghcr.io/voidzero-dev/vite-plus:pr-3249	218MB

# remove any stale local copy from a previous run, then pull fresh
docker rmi ghcr.io/voidzero-dev/vite-plus:pr-3249 2>/dev/null; docker pull ghcr.io/voidzero-dev/vite-plus:pr-3249

Quick check:

docker run --rm ghcr.io/voidzero-dev/vite-plus:pr-3249 vp --version

See docs/guide/docker.md for usage.

[leaysgur]

Another idea might be:

The current approach tries to preserve Vite's config-resolution behavior, including plugin hooks that may modify the config. That introduces complexity and compatibility concerns.

If we can separate Vite's config resolution from reading Vite+-specific fields, we could instead use loadConfigFromFile() to evaluate the config and extract .lint, .fmt, .pack, .staged, etc., without calling resolveConfig()?

Config functions and promises would still be evaluated, and lazyPlugins could still be skipped. However, Vite plugin hooks would not run, so changes they make to these fields would not be supported.

This would avoid P1 and the need to reconstruct a ResolvedConfig. We would still need to define the environment initialization before evaluation for P2.

The main question: whether any consumers need these fields to be modified by Vite plugin hooks?

[fengmk2]

@leaysgur We considered this approach before. It would indeed be much simpler, but it would break the Vite plugin mechanism, so we didn’t choose it.

[leaysgur]

Oh, I see~. Then, let me know if there is anything else I should do.

[liangmiQwQ]

The main question: whether any consumers need these fields to be modified by Vite plugin hooks?

🙌 (I am doing an experiment about Vite+ plugin which depends on this mechanism)

[fengmk2]

Oxc's loadViteConfigField already receives an absolute config path. Use the same resolver selection for CLI and LSP:

vitePlusCache ??= import("vite-plus");
const vitePlus = await vitePlusCache;

const config =
  typeof vitePlus.resolveConfigFromFile === "function"
    ? await vitePlus.resolveConfigFromFile(path)
    : await vitePlus.resolveConfig({ configFile: path }, "build");

Keep the existing field extraction and validation. No rootBase argument or CLI/LSP branch is needed.

The new helper resolves an unset or relative root from the config file's directory, independently of cwd. Absolute roots are preserved. Older Vite+ versions retain their existing cwd-based behavior through the fallback.

Fall back only when the new function is absent. Configuration errors should still propagate.

[leaysgur]

LGTM, I feel like the patch approach is a reasonable trade-off.

As for merging this into Oxc, is it urgent?
If we wait until after the next Vite+ release, checking for the existence of resolveConfigFromFile won't be necessary.
(Well, since we can just remove it in the release after next, it's also fine to release it ahead of Vite+ as suggested above.)

[fengmk2]

@leaysgur Let’s wait until the new Vite+ version is released before updating Oxc. I’m not planning to release a new version this week. Vite+ 1.5.0 is scheduled for next Tuesday.