Using 'loadEnv' in 'vite. config. ts' will result in errors when running' vp lint 'and' vp fmt '

[ywenhao]

Describe the bug

Reproduction

https://github.com/ywenhao/loadEnv-error-demo

Steps to reproduce

vp lint

vp fmt

System Info

Environment:
  Version       24.14.1
  Source        engines.node
  Source Path   /home/actions/code/loadEnv-error-demo/package.json
  Project Root  /home/actions/code/loadEnv-error-demo

Tool Paths:
  node  /home/actions/.vite-plus/js_runtime/node/24.14.1/bin/node
  npm   /home/actions/.vite-plus/js_runtime/node/24.14.1/bin/npm
  npx   /home/actions/.vite-plus/js_runtime/node/24.14.1/bin/npx




vp v0.1.14

Local vite-plus:
  vite-plus  v0.1.14

Tools:
  vite             v8.0.2
  rolldown         v1.0.0-rc.11
  vitest           v4.1.1
  oxfmt            v0.42.0
  oxlint           v1.57.0
  oxlint-tsgolint  v0.17.3
  tsdown           v0.21.4

Environment:
  Package manager  pnpm v10.33.0
  Node.js          v24.14.1 (engines.node)

Used Package Manager

pnpm

Logs

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.

[claude]

Analysis

Understanding the issue: When vite.config.ts uses a function-form config with loadEnv, vp lint and vp fmt fail during config resolution.

Root Cause

When vp lint or vp fmt runs, it needs to read the lint/fmt config from vite.config.ts to pass it to oxlint/oxfmt via -c vite.config.ts. To do this, it calls Vite's resolveConfig({ root: cwd }, 'build') (in packages/cli/src/resolve-vite-config.ts).

When the config is a function form like:

export default defineConfig(({ mode }) => {
  const env = loadEnv(mode, process.cwd())
  return {
    lint: { ... },
    plugins: [vue(), vueDevTools()],
    ...
  }
})

Vite's resolveConfig calls the config function with { mode: 'production', command: 'build' }, which:

1. Invokes loadEnv('production', process.cwd())
2. Initializes all plugins including @vitejs/plugin-vue and vite-plugin-vue-devtools

The plugin initialization in step 2 is the likely source of errors — plugins like vite-plugin-vue-devtools may do things (start servers, access APIs) that fail when called outside a real build/serve context. The loadEnv call is what triggers the function to run, making it appear as the cause.

Relevant files:

• packages/cli/src/resolve-vite-config.ts — calls resolveConfig({ root: cwd }, 'build') for lint/fmt config loading
• packages/cli/binding/src/cli.rs (lines 237–313) — SubcommandResolver::resolve() for Lint/Fmt commands

Fix Plan

The fix is to use static config extraction for lint and fmt, the same approach already used for vp run (see VitePlusConfigLoader::load_user_config_file() in cli.rs, line 616).

The vite_static_config crate already handles function-form configs with loadEnv correctly (there's a test at vite_static_config/src/lib.rs:964). It statically parses the AST and extracts JSON-literal fields without executing any JavaScript.

For the reproduction config, all fields in lint: { ... } and fmt: { ... } are JSON literals (strings, booleans), so they're fully statically extractable.

Implementation steps:

1. crates/vite_static_config/src/lib.rs: Add a resolve_static_config_with_path function (or make resolve_config_path public) so callers can get both the FieldMap and the config file path.

2. packages/cli/binding/src/cli.rs — update SubcommandResolver::resolve() for Lint and Fmt:

   • Call vite_static_config::resolve_static_config_with_path(cwd) first
   • If lint/fmt is FieldValue::Json(v) → use v directly, get config_file from the static path
   • If FieldValue::NonStatic → fall back to existing resolve_universal_vite_config().await?
   • If None → no config present, skip the -c flag

3. Add a snap test in packages/cli/snap-tests/ for vp lint and vp fmt with a function-form config using loadEnv.

This is a low-complexity fix (~50–80 lines of Rust). The static extraction already handles this pattern; it just needs to be wired up for lint/fmt the same way it's already wired for vp run.

---

Note: I wasn't able to see the screenshots in the issue. Could you share the actual error message text? This would help confirm the root cause. The fix plan above should resolve the issue regardless, but knowing the exact error would be useful for writing a targeted test case.