You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
vp lint / vp run lint print no summary on a clean pass (unlike vp exec turbo run lint) #2035
Running vp lint <path> (or vp run lint, the task-runner form) directly prints nothing at all and exits 0 when there are zero lint violations — no "Found 0 warnings and 0 errors" summary, no file/rule count, nothing. The same underlying lint task, when invoked via vp exec turbo run lint --filter=<pkg>, prints the full oxlint summary line even on a clean pass:
manolea-placeholder:lint: $ vp lint .
manolea-placeholder:lint: Found 0 warnings and 0 errors.
manolea-placeholder:lint: Finished in 422ms on 1103 files with 95 rules using 16 threads.
To be clear, this is not a correctness bug — I verified with injected violations that both invocation paths correctly detect and report real problems (a syntax error fails with exit 1 and the parse error text; a debugger; statement prints the eslint(no-debugger) warning by name in both paths). The only difference is the empty-output case.
Why this is worth fixing
Empty stdout + exit 0 is ambiguous to a human running vp lint . locally before pushing: "no output" could mean "ran cleanly" or "didn't actually run" (e.g. wrong cwd, misconfigured filter, crashed silently). The turbo-wrapped invocation resolves that ambiguity by always printing a summary; the direct vp lint/vp run lint invocation doesn't.
Repro
In a workspace with a shared vite.config.ts (via defineConfig(), exporting lint/run/etc. sub-configs) and a package whose package.json has "lint": "vp lint .":
# From the package directory — prints nothing, exit 0cd packages/some-pkg
vp lint .echo$?# 0# From the workspace root — prints a summary even though nothing changed
vp exec turbo run lint --filter=some-pkg --force
Ask
Have vp lint/vp run lint print the same "Found N warnings and M errors. Finished in Xms on Y files with Z rules" summary on a clean pass that vp exec turbo run lint shows, so a passing run is visibly distinguishable from a run that silently did nothing.
I'd like to take this one. Plan: reproduce both invocation paths (direct vp lint vs vp exec), trace where the clean-pass summary is dropped in the bundled-oxlint routing, fix, and cover it with a PTY snapshot case.
Root-caused this before writing a patch, and the finding changes the framing: vp lint already prints the summary in a plain terminal environment. The silence is oxlint's own environment-adaptive format selection, not something vp drops.
Reproduction matrix
All runs against the bundled oxlint 1.79.0, clean file, piped stdout:
Environment
vp lint clean.js output
plain env
Found 0 warnings and 0 errors. + Finished in …
agent env var set (CLAUDECODE, CURSOR_AGENT, AI_AGENT, …)
AI-agent env detected (agent_detection.rs: CLAUDECODE, REPL_ID, GEMINI_CLI, CURSOR_AGENT, AI_AGENT, …) → Agent format, whose finish() unconditionally returns None — the clean-pass summary is omitted by design (less noise for agents; exit code carries the result).
GITHUB_ACTIONS=true → GitHub format (annotations only, no summary).
otherwise → Default format, which always prints the summary.
So a clean vp lint looks like a no-op exactly when it runs inside an AI-agent session or GitHub Actions. I suspect the original comparison ran in such an environment, and the vp exec turbo run lint side resolved an older oxlint (pre agent-detection) — that would fully explain the asymmetry.
Options
(a) Working as intended upstream — close, possibly with a docs note. Humans in terminals already get the summary; the silent modes are deliberate upstream choices.
(b) vp-level override — have vp lint pass --format default when the user didn't specify a format. Trade-off: it defeats oxlint's agent mode and loses GitHub annotations in Actions, so it would need to be conditional and I'm not sure the complexity pays for itself.
I claimed this intending to patch, but I'd rather not code (b) before a maintainer weighs in on whether this is a bug at all. Happy to implement whichever direction is preferred — or close it as (a).
Activity
fix(lint): always print summary on clean vp lint pass
fix(lint): always print summary on clean vp lint pass
fix(lint): always print summary on clean vp lint pass
simulacre7 commentedon Aug 21, 2026
I'd like to take this one. Plan: reproduce both invocation paths (direct
vp lintvsvp exec), trace where the clean-pass summary is dropped in the bundled-oxlint routing, fix, and cover it with a PTY snapshot case.simulacre7 commentedon Aug 21, 2026
Root-caused this before writing a patch, and the finding changes the framing:
vp lintalready prints the summary in a plain terminal environment. The silence is oxlint's own environment-adaptive format selection, not something vp drops.Reproduction matrix
All runs against the bundled oxlint 1.79.0, clean file, piped stdout:
vp lint clean.jsoutputFound 0 warnings and 0 errors.+Finished in …CLAUDECODE,CURSOR_AGENT,AI_AGENT, …)GITHUB_ACTIONS=true--format defaultMechanism (upstream oxlint)
When
--formatis not passed, oxlint picks the format inapps/oxlint/src/command/lint.rs→default_output_format():agent_detection.rs:CLAUDECODE,REPL_ID,GEMINI_CLI,CURSOR_AGENT,AI_AGENT, …) → Agent format, whosefinish()unconditionally returnsNone— the clean-pass summary is omitted by design (less noise for agents; exit code carries the result).GITHUB_ACTIONS=true→ GitHub format (annotations only, no summary).So a clean
vp lintlooks like a no-op exactly when it runs inside an AI-agent session or GitHub Actions. I suspect the original comparison ran in such an environment, and thevp exec turbo run lintside resolved an older oxlint (pre agent-detection) — that would fully explain the asymmetry.Options
vp lintpass--format defaultwhen the user didn't specify a format. Trade-off: it defeats oxlint's agent mode and loses GitHub annotations in Actions, so it would need to be conditional and I'm not sure the complexity pays for itself.I claimed this intending to patch, but I'd rather not code (b) before a maintainer weighs in on whether this is a bug at all. Happy to implement whichever direction is preferred — or close it as (a).