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:

1. The version from the issue (if specified) — to confirm the bug exists
2. 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.