perf: `oxlint` and `oxfmt` each load `vite.config.ts` twice per invocation

[ryansuhartanto]

Describe the bug

A single vp staged run evaluates the project's vite.config.ts 8 times.

The repro puts a side effect at the top of the config that appends one line per evaluation, recording timestamp, pid and argv:

import { appendFileSync } from 'node:fs';

appendFileSync(
  new URL('./config-loads.log', import.meta.url),
  `load ${Date.now()} pid=${process.pid} argv=${process.argv.slice(1).join(' ')}\n`,
);

export default {
  staged: { '*.ts': 'vp check --fix' },
};

With 3 staged .ts files, one vp staged run produces 8 lines (paths and arguments elided for width):

load ... pid=137436 argv=.bin/vp staged
load ... pid=137479 argv=.bin/vp check --fix f1.ts f2.ts f3.ts
load ... pid=137513 argv=oxfmt/bin/oxfmt --no-error-on-unmatched-pattern f1.ts f2.ts f3.ts
load ... pid=137513 argv=oxfmt/bin/oxfmt --no-error-on-unmatched-pattern f1.ts f2.ts f3.ts
load ... pid=137573 argv=oxlint/bin/oxlint --fix --format=default --no-error-on-unmatched-pattern f1.ts f2.ts f3.ts
load ... pid=137573 argv=oxlint/bin/oxlint --fix --format=default --no-error-on-unmatched-pattern f1.ts f2.ts f3.ts
load ... pid=137654 argv=oxfmt/bin/oxfmt --no-error-on-unmatched-pattern f1.ts f2.ts f3.ts
load ... pid=137654 argv=oxfmt/bin/oxfmt --no-error-on-unmatched-pattern f1.ts f2.ts f3.ts

Four processes load the config, and oxfmt and oxlint each load it twice within the same pid.

Timings from the same repo and the same 3 staged files, averaged over 3 runs (vp v0.3.1, Node v26.8.2, bun 1.4.2):

	Time
oxfmt then oxlint, invoked directly	0.045s
vp check --fix, no vite.config.ts present	0.156s
vp check --fix, one-line static vite.config.ts	0.957s
vp check --fix, instrumented vite.config.ts	0.917s
vp staged, no-op task	0.274s
vp staged, running vp check --fix	1.004s

The config used for the 0.957s row has no imports, no plugins and no side effects:

export default { staged: { '*.ts': 'vp check --fix' } };

So the difference between the 0.156s and 0.957s rows is attributable to the presence of the config file rather than to plugin evaluation, and lazyPlugins does not apply since there is nothing to lazy-load. The instrumented config measures the same as the one-line one, so the appendFileSync is not contributing meaningfully.

Adding .oxlintrc.json and .oxfmtrc.json reduces vp check --fix to 0.680s but does not eliminate the loads: the config is still evaluated 7 times in a single run.

vite.config.ts is expected to evaluate once per vp staged run, or the result is cached and reused across the processes that need it.

Reproduction

https://github.com/ryansuhartanto/vite-plus-staged-perf

Steps to reproduce

After cloning:

bun install
./bench.sh

System Info

VITE+ - The Unified Toolchain for the Web

vp v0.3.0

Local vite-plus:
  vite-plus  v0.3.1

Tools:
  vite             v8.2.2
  rolldown         v1.2.7
  vitest           v4.1.11
  oxfmt            v0.66.0
  oxlint           v1.81.0
  oxlint-tsgolint  v7.0.2001
  tsdown           v0.23.0

Used Package Manager

bun

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.

[ryansuhartanto]

The source problem seems to be outside of the repo at oxc
https://github.com/oxc-project/oxc/blob/main/apps/shared/src-js/vite_plus_config.ts

Should I make a separate issue there?

[liangmiQwQ]

That is really solid feedback. Thanks for looking into this.

Since these config loading are all by Vite+ commands, I think we can try improving that in Vite+ first.

[liangmiQwQ]

After analyzing, I found this is caused by Vite+'s conditional -c vite.config.ts injection.

Oxlint / Oxfmt has a logic, when -c <configfile> is set, but the config file doesn't have lint / fmt config field, it will drop an error and stop working instead of using the default config.

So, to prevent this error, Vite+ would stop injecting this argument when root vite.config.ts don't have lint / fmt config. This makes nested config will be loaded, and Oxc's internal config walker would let the root vite.config.ts to be read twice. Moreover, it also causes nested config to be loaded when root vite.config.ts don't have lint / fmt configuration.

Switching to --disable-nested-config in Oxlint & Oxfmt cli couldn't help, because it applies for the <cwd>/vite.config.ts not the project root's one.

I think one feasible solution is to stop rejecting unconfigured lint / fmt on Oxc side, so Vite+ can always inject this arguments.

/cc @fengmk2 @leaysgur

[ryansuhartanto]

Thanks @liangmiQwQ for pinpointing the conditional injection, it checks out on my testing.

I did try memoizing the config load in that file earlier, but the ~22ms saved didn't justify the LSP holding stale config until restart.

The per-child cost is the vite-plus import itself, ~252ms, plus ~60ms for the first resolveConfig. Always injecting -c removes the second evaluation per child and the nested lookup, but each child still pays that import once, which is most of the 1.0s vs 0.22s.

What I don't understand yet: with .oxlintrc.json and .oxfmtrc.json present, oxfmt and oxlint still evaluate vite.config.ts. Is an explicit rc file meant to short-circuit the vite config lookup? If it did, the children would never import vite-plus at all. Also, each child evaluates twice, 16-54ms apart, which looks like two independent call sites rather than one chain. What are the two entry points?

[liangmiQwQ]

Thanks @liangmiQwQ for pinpointing the conditional injection, it checks out on my testing.

I did try memoizing the config load in that file earlier, but the ~22ms saved didn't justify the LSP holding stale config until restart.

The per-child cost is the vite-plus import itself, ~252ms, plus ~60ms for the first resolveConfig. Always injecting -c removes the second evaluation per child and the nested lookup, but each child still pays that import once, which is most of the 1.0s vs 0.22s.

What I don't understand yet: with .oxlintrc.json and .oxfmtrc.json present, oxfmt and oxlint still evaluate vite.config.ts. Is an explicit rc file meant to short-circuit the vite config lookup? If it did, the children would never import vite-plus at all. Also, each child evaluates twice, 16-54ms apart, which looks like two independent call sites rather than one chain. What are the two entry points?

1. Skipping .oxlintrc.json, and .oxfmtrc.json is the expected behavior, Oxlint and Oxfmt only read vite.config.ts in Vite+. IMO that makes sense because users are using the product Vite+, not Oxlint / Oxfmt so it should read its own config semantically.
2. For two independent call for one process, it's just caused by the problem I mentioned above. It is an internal problem about nested config in Vite+ & Oxlint bridge.
3. Cache or memoizing the config file for multiple calls in one command might be a great enhancement, but It's a bit complicated so I think we should focus on the second problem first.