---
title: Debugging | Introduction
description: Learn a few debugging tips to streamline your journey with Qwik.
contributors:
  - gioboa
  - KyeongJooni
updated_at: '2025-12-13T00:00:00Z'
created_at: '2025-08-08T00:00:00Z'
---

import { Note } from '~/components/note/note';

# Debugging

## ✨ Save yourself a bit of time with 'click to source'

During development, you can quickly access the source code of any element on a webpage by holding Option (⌥) or Alt key,
click on whatever you're curious about, and Qwik will immediately open your source code right on top of that element.
Seriously, any component, link, header - you name it, you can peek at its code.

Qwik tries to guess what code editor you like to use.
If it guesses wrong, no biggie! Just give Qwik a hint by setting the `LAUNCH_EDITOR` environment variable.
For example, if you're on a Mac and use VS Code, you'd type `export LAUNCH_EDITOR=code` in your terminal.

Under the hood [launch-editor library](https://github.com/yyx990803/launch-editor/tree/master) is used, here are the [supported editors](https://github.com/yyx990803/launch-editor/tree/master?tab=readme-ov-file#supported-editors)

## Finding leftover `console.log` statements

When working on larger codebases, you might occasionally leave `console.log` statements in your code unintentionally. These can clutter your terminal output, and it's often difficult to identify which file and line number produced each log message.

### Using ESLint rules (recommended)

The recommended approach is to configure ESLint to prevent `console.log` statements from being committed:

```js
// eslint.config.js
export default [
  {
    rules: {
      'no-console': ['error', { allow: ['warn', 'error'] }],
    },
  },
];
```

This will catch `console.log` statements during development, preventing them from being committed.

### Using IDE search

Most IDEs provide powerful search functionality to find all occurrences of `console.log` across your codebase:
- **VS Code**: Press `Ctrl+Shift+F` (or `Cmd+Shift+F` on Mac) and search for `console\.log`
- **Enable regex mode** to match only exact `console.log` calls and not `console.error` or `console.warn`

This approach is simple but requires manual review of each occurrence to determine if it's intentional or leftover debug code.

### Using stack traces (temporary debugging)

If you need to identify existing leftover console.logs in a codebase that's already cluttered, you can temporarily override `console.log` to include stack traces.

#### In client-side components

You can override `console.log` in your component code:

```tsx
// root.tsx or layout.tsx
export default component$(() => {
  // Override console.log to include stack traces
  useVisibleTask$(() => {
    const originalLog = console.log;
    console.log = (...args: any[]) => {
      const stack = new Error()
        .stack?.split('\n')
        .filter((i) => !/^.*(\.vite|\.main\.jsx|node_modules).*/.test(i));
      originalLog(stack, ...args);
    };
  });

  return (
    // your component JSX
  );
});
```

#### In server-side entry files

For entry files like `entry.express.tsx`, `entry.dev.tsx`, or `entry.preview.tsx`, you can override `console.log` at the module level:

```tsx
// entry.express.tsx or entry.dev.tsx or entry.preview.tsx

// Override console.log at the top level
const originalLog = console.log;
console.log = (...args: any[]) => {
  const stack = new Error()
    .stack?.split('\n')
    .filter((i) => !/^.*(node_modules|internal).*/.test(i));
  originalLog(stack, ...args);
};

// Rest of your entry file code...
```

<Note>Remember to remove these overrides after debugging. The filter regex should be adjusted based on your specific build setup.</Note>
