vibecheck0.3.0
Performanceconsole-spamwarning

Console.log spam

Debug logs left in shipped code serialize their arguments on every call, add DevTools overhead, and in a hot path (a render loop, a scroll handler) they measurably slow the page. They also leak app internals to anyone who opens the console and bury the one real error under noise. Vibe-coded features accumulate these fast, because logging is how the agent "sees" while it works — and it rarely cleans up.

Framework fixes
GeneralReactNext.jsVueVanilla JS

Symptoms

  • The console is a wall of messages on a normal page load
  • App state, tokens, or payloads are visible to anyone who opens DevTools
  • A genuine error is impossible to find in the noise
  • Perceptible slowdown in loops that log on every iteration

How VibeCheck catches it

In your widget · Problems

warningconsole-spamconsole.log spam detected

To your coding agent · MCP

agent › get_detected_issues
→ { detector: "console-spam", issue: "console.log spam detected", threshold: "> 20 console calls within a rolling 10s window" }

The same string in your widget and in your agent’s context — no screenshot, no copy-paste.

Root causes

  • Debug console.log statements never removed after a feature shipped
  • A verbose third-party library logging at its default level
  • Logging inside a render, effect, or scroll/resize handler that fires constantly

The fix

Strip console output at build time for production, keep intentional error reporting behind a level-aware logger, and add an ESLint no-console rule so new debug logs can’t be merged. Configure noisy libraries down to warn/error.

  1. Enable build-time console stripping for production builds
  2. Replace ad-hoc logs with a logger that is silent in production
  3. Add the ESLint no-console rule (allowing warn/error) to prevent regressions
.eslintrc — block new debug logsjson
{ "rules": { "no-console": ["error", { "allow": ["warn", "error"] }] } }

FAQ

Should I remove console.error too?
No — keep console.error (and usually console.warn) so genuine failures still surface. Strip only the debug-level console.log/info/debug noise. The examples here exclude error on purpose.
Is console.log actually a performance problem?
In a hot path, yes. Each call serializes its arguments and incurs DevTools overhead. One log on click is nothing; a log inside a scroll handler or render loop firing hundreds of times a second is measurable.
How does VibeCheck count this?
It wraps console.log/warn/error and counts calls in a rolling 10-second window. More than 20 in that window trips the console-spam detector.