Console Cleanup

Remove console statements in production

Console statements leak sensitive information, impact performance, and create unprofessional user experiences when visible in production.

Quick Reference

• Remove console.log, console.debug, console.table before production
• Use environment-aware logging utilities
• Configure build tools to strip console statements automatically
• Keep console.error for critical error tracking if needed

Check

Scan this JavaScript code for console.log, console.debug, console.warn, console.error, and other console statements that should be removed before production deployment.

Fix

Remove or conditionally disable console statements for production, or replace them with a proper logging service.

Explain

Explain why console statements should be removed from production code and alternatives for logging.

Code Review

Review scripts, client components, and browser execution paths related to Remove console statements in production. Flag exact imports, event handlers, runtime side effects, or blocking operations that violate the rule, and state how the change should be verified in the browser.

---

For full implementation details, code examples, and framework-specific guidance, see references/rule.md.

Rule page: https://frontendchecklist.io/en/rules/javascript/console-cleanup

Remove console statements in production

Remove or disable console.log, console.debug, and other console statements before deploying to production.

Priority: medium · Difficulty: beginner · Time: 10 min

--- Console statements left in production code can leak sensitive information, impact performance, and create a poor user experience.

Code Example

#

Common Console Methods to Remove

// ❌ Remove before production
console.log('User data:', userData)
console.debug('API response:', response)
console.info('Feature flag enabled')
console.table(results)
console.time('operation')
console.timeEnd('operation')
console.trace('Call stack')
console.group('Group')
console.groupEnd()

// ✅ Keep for legitimate purposes
console.error('Critical error:', error)  // May keep for error tracking
console.warn('Deprecation notice')        // May keep for developer warnings

Why It Matters

Console statements leak sensitive information, impact performance, and create unprofessional user experiences when visible in production.

Best Practices

Conditional Logging

// ✅ Good: Environment-aware logging
const isDev = process.env.NODE_ENV === 'development'

function log(...args) {
  if (isDev) {
    console.log(...args)
  }
}

// Usage
log('Debug info:', data)

Using a Logging Service

// ✅ Good: Structured logging service

// Development: logs to console
// Production: logs to service (Sentry, LogRocket, etc.)
logger.info('User logged in', { userId: user.id })
logger.error('API failed', { endpoint, error })

Build Tool Configuration

Linter Configuration

    // .eslintrc.js
    module.exports = {
      rules: {
        'no-console': process.env.NODE_ENV === 'production'
          ? 'error'
          : 'warn'
      }
    }

    // biome.json
    {
      "linter": {
        "rules": {
          "suspicious": {
            "noConsoleLog": "warn"
          }
        }
      }
    }

Webpack (Terser)

// webpack.config.js
module.exports = {
  optimization: {
    minimizer: [
      new TerserPlugin({
        terserOptions: {
          compress: {
            drop_console: true
          }
        }
      })
    ]
  }
}

Vite

// vite.config.js

  build: {
    terserOptions: {
      compress: {
        drop_console: true,
        drop_debugger: true
      }
    }
  }
}

Standards

• Use MDN: JavaScript Guide as the standard for how this JavaScript pattern should behave in production, not just in a small local example.
• Use web.dev: Learn JavaScript as the standard for how this JavaScript pattern should behave in production, not just in a small local example.

Verification

Automated Checks

• Verify the behavior in the browser after the code change, not only in static analysis.
• Inspect DevTools Network or Performance panels when the rule affects loading or execution order.
• Test the primary user flow and one edge case triggered by the changed script path.

Manual Checks

• Confirm the code still behaves correctly when the feature is delayed, lazy-loaded, or fails.