Remove console statements in production
Remove or disable console.log, console.debug, and other console statements before deploying to production.
- 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
Rule Details
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 warningsWhy 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
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
// .eslintrc.js
module.exports = {
rules: {
'no-console': process.env.NODE_ENV === 'production'
? 'error'
: 'warn'
}
}Webpack (Terser)
// webpack.config.js
module.exports = {
optimization: {
minimizer: [
new TerserPlugin({
terserOptions: {
compress: {
drop_console: true
}
}
})
]
}
}Vite
// 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.
Use with AI
Copy these prompts to use with your AI assistant, or install the MCP server to use directly from Claude, Cursor, or Windsurf.
Check
Verify implementation
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
Auto-fix issues
Remove or conditionally disable console statements for production, or replace them with a proper logging service.
Explain
Learn more
Explain why console statements should be removed from production code and alternatives for logging.
Review
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.