JavaScriptmediumbest-practices

Remove console statements in production

rule · console-cleanup

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

JavaScript

// ❌ 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

JavaScript

// ✅ 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

JavaScript

// ✅ Good: Structured logging service
import { logger } from './logger'
 
// 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

Webpack (Terser)

JavaScript

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

Vite

JavaScript

// vite.config.js
export default {
  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.