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 is used, here are the 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 stack traces in client-side components

You can override console.log to include stack trace information in your component code. For example, in your root component or a layout component:

// 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
  );
});

Now when you call console.log("something"), you'll see the stack trace pointing to the exact location where the log was called, making it much easier to locate and remove leftover debug statements.

Using stack traces 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:

// 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: The filter regex should be adjusted based on your specific build setup. Common patterns to filter out include .vite, .main.jsx, node_modules, and internal paths.

Using ESLint rules

You can configure ESLint to warn or error on console.log statements in production code:

// 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. For example:

• 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.