Metadata-only config loads run `resolveConfig`, which reads `node_modules/.modules.yaml`; cached tasks that run `vp`, `oxlint` or `oxfmt` miss after every reinstall
メンテナーはふだん 1 日以内に返信
@wan9chi がすでに取り組んでいます。
2026年9月28日 から。
評価
この issue はまだ評価されていません。
説明
Describe the bug
Every metadata read of vite.config.* goes through Vite's full resolveConfig(…, 'build'): vp run's task lookup, vp check/lint/fmt/staged/pack/create (packages/cli/src/resolve-vite-config.ts:86-101), and the loadViteConfigField that oxlint and oxfmt call in Vite+ mode. resolveConfig runs resolveServerOptions, which reads node_modules/.modules.yaml to derive the dev server's server.fs.allow from pnpm's virtualStoreDir. Nothing about reading a run, lint or fmt block needs that, and lazyPlugins cannot help: the read is Vite's own, not a plugin's.
Under Vite Task this is a cache bug. pnpm rewrites .modules.yaml on every install (prunedAt) and it carries the machine's storeDir, so with { auto: true } tracking any cached task whose process tree runs vp, oxlint or oxfmt records it as an input. The task misses after every reinstall and can never replay on another machine.
Stack, from an fs hook loaded through NODE_OPTIONS=--require:
readFileSync(node_modules/.modules.yaml)
at resolveServerOptions (@voidzero-dev/vite-plus-core/dist/vite/node/chunks/node.js:30392)
at async resolveConfig (…/chunks/node.js:42610)
at async withConfigMetadataResolution (vite-plus/dist/define-config-DhEJaYRc.js:575)
at async resolveUniversalViteConfig (vite-plus/dist/resolve-vite-config-BJYYtfY3.js:75)
vp fmt --check src produces the same read from oxfmt/dist/cli.js:141 (loadViteConfigField → resolveConfig); oxlint's dist/js_config.js makes the identical call.
The only line that differs between two installs of the same lockfile:
- "prunedAt": "Mon, 28 Sep 2026 12:55:07 GMT",
+ "prunedAt": "Mon, 28 Sep 2026 12:58:26 GMT",
Reproduction
Three files.
// package.json
{ "name": "probe", "private": true, "type": "module", "packageManager": "[email protected]", "devDependencies": { "vite-plus": "1.0.0" } }
// vite.config.ts
import { defineConfig } from 'vite-plus';
export default defineConfig({
fmt: {},
run: {
tasks: {
// A cached task whose process tree runs a `vp` built-in.
fmt: {
command: "sh -c 'vp fmt --check src'",
cache: { input: [{ auto: true }], output: [] },
},
},
},
});
// src/a.ts
export const a = 1;
Steps to reproduce
vp install
export VITE_CACHE_PATH="$PWD/.task-cache" # keep the task cache outside node_modules
vp run fmt # executes
vp run fmt # ◉ cache hit, replaying
rm -rf node_modules && vp install # same lockfile, same versions
vp run fmt # ○ cache miss: 'node_modules/.modules.yaml' modified
Replacing the two resolveConfig calls (vite-plus's resolveViteConfig and oxfmt's loadViteConfigField) with loadConfigFromFile(configEnv, configFile, cwd) and repeating the steps: the run after the reinstall is a cache hit, and the hook records zero reads of .modules.yaml.
Suggested fix
Load metadata with Vite's public loadConfigFromFile instead of resolveConfig. It evaluates the config file (including function configs, with a ConfigEnv) and returns the user config object, which is all the metadata paths read.
// packages/cli/src/resolve-vite-config.ts
export async function resolveViteConfig(cwd: string, options?: ResolveViteConfigOptions) {
const { loadConfigFromFile } = await import('./index.js');
return withConfigMetadataResolution(async () => {
let configFile: string | undefined;
if (options?.traverseUp && !hasViteConfig(cwd)) {
const workspaceRoot = findWorkspaceRoot(cwd);
if (workspaceRoot) configFile = findViteConfigUp(path.dirname(cwd), workspaceRoot);
}
const result = await loadConfigFromFile(
{ command: 'build', mode: 'production', isSsrBuild: false, isPreview: false },
configFile,
cwd,
);
return result ? { ...result.config, configFile: result.path } : { configFile: undefined };
});
}
Two notes:
resolveConfigalso setprocess.env.NODE_ENVas a side effect; withloadConfigFromFilethe caller decides. We default it explicitly in our patch.- oxlint's and oxfmt's
loadViteConfigFieldneed the same swap, or avite-plusexport they can call.
We have run exactly this as pnpm patches of vite-plus, oxlint and oxfmt in production CI since 2026-09-08, across 1.0.0-rc.0, rc.1 and 1.0.0.
Related: #2698 (the same loads happen up to 8× per vp staged), #1756 and #1580 (plugin side effects on the same path, addressed by lazyPlugins), #2307.
System Info
vite-plus 1.0.0 (project), vp 1.0.0-rc.1 (global launcher)
vite 8.3.1, rolldown 1.2.11, oxfmt 0.70.0, oxlint 1.85.0
Node.js v24.21.0 (project runtime), pnpm 12.4.1
macOS 27.0, arm64; the same miss was first observed on Linux CI runners (Ubuntu 24.04)
Used Package Manager
pnpm
Logs
$ sh -c 'vp fmt --check src' ○ cache miss: 'node_modules/.modules.yaml' modified, executing
Checking formatting...
All matched files use the correct format.
Finished in 69ms on 1 files using 10 threads.
Statistics: 1 tasks • 0 cache hits • 1 cache misses
Task Details:
[1] probe#fmt: $ sh -c 'vp fmt --check src' ✓
→ Cache miss: 'node_modules/.modules.yaml' modified
Validations
- Read the Contributing Guidelines.
- Check that there isn't already an issue for the same bug.
- Confirm this is a Vite+ issue and not an upstream issue (Vite, Vitest, tsdown, Rolldown, or Oxc).
- The provided reproduction is a minimal reproducible example.
- 主要言語
- Rust
- スター
- 5.8k
- フォーク
- 267
- 平均マージ
- 21時間 10分
- マージ済み PR(30日)
- 148
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
voidzero-dev/vite-plus のほかの issue
-
pending triage
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
voidzero-dev/vite-plus#2801 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
voidzero-dev/vite-plus#2097 · コメント 10 件 · リアクション 2 件 ·
メンテナーはふだん 1 日以内に返信
-
vp check --no-lint still reports type-aware lint rules and ignores their disable comments対応中かも @camc314 が 2 日前に担当しました。 オープン
voidzero-dev/vite-plus#2830 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
vp run: task output forwarding aborts with EAGAIN when stdout turns non-blocking mid-run (follow-up to #2165)対応中かも @naokihaba が 3 日前に担当しました。 オープンbug
voidzero-dev/vite-plus#2824 · コメント 3 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
pending triage
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
voidzero-dev/vite-plus#2816 ·
メンテナーはふだん 1 日以内に返信
voidzero-dev/vite-plus の issue をすべて見る
似ている issue
-
backend::vllm diffusion multimodal
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
lambdaclass/ethrex#7329 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
shadowsocks/shadowsocks-rust#2186 · コメント 1 件 ·
-
C-bug S-awaiting-triage
難易度 1/5 1時間未満 初心者へのやさしさ 92/100
juspay/hyperswitch#14479 ·
メンテナーはふだん 1 日以内に返信