How to Remove console.log in Production (and What to Use Instead) (video)

Leftover console.log calls leak data, clutter the browser console, and slow hot paths. Learn how to stop them with ESLint, strip them at build time in Vite, esbuild, or webpack, and replace them with a real logger.

Read the full article

Transcript

How to Remove console.log in Production (and What to Use Instead). Here's the short version.

console.log is the fastest way to debug JavaScript, which is exactly why so many of them end up in production. In the browser they expose internal data to anyone who opens DevTools.

Why leftover console.log is a problem. Data exposure: tokens, user records, and API responses printed to the browser console are visible to anyone. Noise: real warnings get buried under debug output. Performance: logging large objects in hot paths or loops costs time and memory, and keeps objects alive for DevTools. Unstructured server logs: plain strings cannot be filtered by user, request, or level.

Here's an example: eslint.config.js: allow warn and error, flag everything else.

Step 2: strip them from production builds. Dropping all console calls also removes console.error. If you rely on it for error reporting, use Terser's pure_funcs option to drop only console.log and console.debug.

Step 3: use a real logger. On Node.js, a structured logger such as pino or winston writes JSON with levels and fields. In the browser, send errors to an error-tracking service instead of the console.

Want to find these issues in your own code? Connect your GitHub repository to CodeInspector. You'll get findings with the file, line, severity, and a recommended fix, plus HTML and PDF reports for your team. Start free at codeinspector.app.

More videos

All videos