Issue Triage

Deno Issue Triage

Triage issue $ARGUMENTS on the denoland/deno repository.

Step 1: Read the issue

gh issue view $ARGUMENTS --repo denoland/deno --json number,title,body,author,labels,state,comments,createdAt,url

Step 2: Classify the issue

Determine what kind of issue this is:

• Bug report — something isn't working as expected
• Feature request / suggestion — a new capability or enhancement
• Question — a usage question, not a bug
• Duplicate — already reported (search closed and open issues with

gh issue list --search "keywords" --state all)

• Invalid — not actionable, not a Deno issue, or insufficient info

If the issue is clearly a question, duplicate, or invalid, skip reproduction and

go straight to Step 5.

Step 3: Check for missing information

A valid bug report needs:

• Deno version (deno --version output)
• Operating system
• Reproduction steps or minimal reproduction code
• Expected behavior vs actual behavior

If any of these are missing, label as needs info and comment asking the author

to provide the missing details. Do not attempt reproduction without a clear

repro case.

Step 4: Reproduce the bug

Only attempt reproduction for bug reports that have a clear repro case.

Setup

Prefer running reproductions inside a Docker container for isolation. Fall back

to a local temp directory only if Docker is unavailable.

Docker (preferred):

# Run repro with latest canary
docker run --rm -v "$REPRO_DIR":/repro -w /repro denoland/deno:canary deno run repro.ts

# Run repro with a specific version (e.g., 2.1.4)
docker run --rm -v "$REPRO_DIR":/repro -w /repro denoland/deno:2.1.4 deno run repro.ts

Use docker run --rm so containers are cleaned up automatically. Mount the

repro files via -v.

Local fallback (if Docker is not available):

REPRO_DIR=$(mktemp -d)
deno run "$REPRO_DIR/repro.ts"

Get Deno versions

Try to reproduce with both:

• The version from the issue (if specified) — to confirm the bug exists
• Latest canary — to check if it's already fixed

Use the appropriate Docker image tag for each version (e.g.,

denoland/deno:2.1.4, denoland/deno:canary).

If the issue specifies a particular Deno version and the bug does NOT reproduce

on canary, note that it may already be fixed. Check git log for relevant fixes.

Run the reproduction

• Extract the reproduction code from the issue body
• Write it to a local temp directory
• Run it inside a Docker container (or locally as fallback) with the appropriate

deno subcommand and flags

• Capture both stdout and stderr
• Compare actual output against the expected behavior described in the issue

If the reproduction involves specific npm packages, deno.json config, or

multi-file setups, recreate the full environment as described.

Clean up

rm -rf "$REPRO_DIR"

Record findings

Note:

• Does the bug reproduce on the reported version?
• Does the bug reproduce on canary?
• Any additional observations (e.g., different error message, partial fix,

related issues)

Step 5: Label the issue

Add labels based on your classification. Keep it minimal — usually a single area

label is sufficient. Do not over-label.

Type labels (add one if applicable)

| Label | When to use |

| ------------ | --------------------------------------------------- |

| bug | Confirmed bug — always add for verified bug reports |

| feat | Accepted new feature |

| suggestion | Feature request not yet accepted |

| question | Usage question |

| duplicate | Duplicate of another issue |

| invalid | Not actionable |

| panic | Deno panics/crashes |

| regression | Something that used to work but is now broken |

Area labels (add one that best matches)

| Label | Area |

| -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- |

| node compat | General Node.js compatibility |

| node API | Specific node:* module APIs |

| ext/node, ext/fs, ext/net, ext/http, ext/fetch, ext/web, ext/crypto, ext/console, ext/url, ext/websocket, ext/kv | Specific extension |

| cli | CLI behavior, flags, subcommands |

| lsp | Language server |

| runtime | Runtime crate |

| permissions | Permission system |

| compile | deno compile |

| testing | deno test and coverage |

| task runner | deno task |

| install | deno install / deno add |

| tsc | TypeScript compiler |

| types | TypeScript type issues |

| config | deno.json configuration |

| node resolution | Node/npm module resolution |

| publish | deno publish |

| lint | deno lint |

| wasm | WebAssembly |

Priority labels (add only when clearly warranted)

| Label | When to use |

| --------------- | ------------------------------------------- |

| high priority | Severe impact, blocks users, security issue |

| quick fix | Obviously simple fix |

Adding labels

gh issue edit $ARGUMENTS --repo denoland/deno --add-label "bug"

Remove the needs triage or triage required 👀 label if present:

gh issue edit $ARGUMENTS --repo denoland/deno --remove-label "needs triage" --remove-label "triage required 👀"

Step 6: Comment on the issue

Post a triage comment with your findings. Structure:

For confirmed bugs:

Confirmed on [version]. [Brief description of what you observed.]

[If tested on canary: "Also reproduces on canary." or "Does not reproduce on canary — may already be fixed."]

For needs info:

Thanks for reporting. Could you provide [missing info]? This will help us investigate.

For duplicates:

This looks like a duplicate of #XXXX. Closing in favor of that issue.

For questions:

This is a usage question rather than a bug. [Brief answer or pointer to docs.] Closing this — feel free to ask on https://discord.gg/deno if you have more questions.

Posting the comment

gh issue comment $ARGUMENTS --repo denoland/deno --body "comment text"

Close the issue if it's a duplicate, question, or invalid:

gh issue close $ARGUMENTS --repo denoland/deno --reason "not planned"

Rules

• Always confirm with the user before posting comments or modifying labels on

GitHub.

• Do not close bug reports — only close duplicates, questions, and invalid

issues.

• Keep labels minimal. One type label + one area label is usually enough.
• Be kind to reporters. Thank them, especially first-time reporters.
• If you cannot reproduce a bug, say so honestly — do not guess at causes.
• If the reproduction requires permissions or resources you don't have access

to, note that and skip reproduction.

• Never dismiss an issue without investigation.