# Debugging and editor setup

## VS Code extension

Install the official extension `denoland.vscode-deno`, then run **Deno: Initialize Workspace Configuration** from the command palette. It writes this into your workspace `.vscode/settings.json`:

```json
{
  "deno.enable": true
}
```

- Enable per workspace only, never in user settings — otherwise every project is treated as a Deno project.
- Once enabled, the extension hands off to the Deno language server and mutes VS Code's built-in TS/JS diagnostics.
- In mixed repositories, use `deno.enablePaths` to activate Deno only in subfolders (e.g. `./supabase/functions`).

Other editors attach to the same language server over LSP:

```bash
deno lsp
```

When something misbehaves, check **Deno: Language Server Status** in the command palette to confirm the active configuration first.

## Inspector breakpoints

Deno speaks the V8 Inspector protocol, with three flags for three startup modes:

| Flag | Behavior |
| --- | --- |
| `--inspect` | Starts the debug server; code runs immediately |
| `--inspect-wait` | Waits for a debugger to attach before running |
| `--inspect-brk` | Waits, then breaks on the first line |

The default address is `127.0.0.1:9229`. Open `chrome://inspect` in a Chromium-based browser and click **Inspect** next to the target to set breakpoints and step through code; source maps show your original TypeScript.

VS Code connects with an attach configuration:

```json title=".vscode/launch.json"
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Attach to dev server",
      "type": "node",
      "request": "attach",
      "port": 9229
    }
  ]
}
```

```bash
deno run --inspect-wait --allow-net main.ts
```

<Callout type="warn" title="Keep the inspector on 127.0.0.1">
An inspector exposed on a routable address is remote arbitrary code execution. Inside containers, debug via port forwarding or exec — never ship `--inspect=0.0.0.0:9229` in a production image.
</Callout>

## Tracing permissions and leaks

When a permission error's origin is unclear, ask the runtime for the triggering stack:

```bash
DENO_TRACE_PERMISSIONS=1 deno run main.ts
```

When tests report leaked resources or async ops, trace their source:

```bash
deno test --trace-leaks
```

`--trace-leaks` slows test execution down; remove it once the leak is found instead of leaving it in CI. Both are diagnostics only — their output points at the cause, it does not fix it.

## Logging layers

- During development, `console.log` / `console.error` write to stdout/stderr, which container platforms collect natively.
- In production, emit structured JSON logs (one object per line with `level`, `msg`, `requestId` fields) instead of free text that needs regex parsing.
- Turn on `--log-level=debug` for the Deno runtime's own diagnostics (module resolution, network, permission decisions), and turn it off once the problem is found; third-party library log levels are controlled by each library's own configuration and are out of this flag's reach.
- Logs never contain secrets or personal data; see [Environment variables and .env](/en/docs/core/env-variables).

Official references: [Debugging](https://docs.deno.com/runtime/fundamentals/debugging/), [VS Code](https://docs.deno.com/runtime/reference/vscode/), [deno test](https://docs.deno.com/runtime/reference/cli/test/).