A JavaScript and TypeScript runtime with integrated development tools.
JavaScript unit tests still run through Cargo because the harness supplies their setup.
├── └── .github └──
The file, explained
Deno's CLAUDE.md combines a runtime overview with development commands and test recipes. It explains the split between the CLI, runtime assembly, and native extensions, then shows how spec tests encode commands and expected output. Contribution guidance keeps review history incremental and chooses lint scope based on whether Rust changed.
Quoted passages are verbatim. Open one to see it in the source.
01 / Hard prohibitions
The guide explicitly warns against running JavaScript and TypeScript unit tests directly with the Deno binary. Cargo owns the setup those tests need.
Source excerpt starting at line 175.Do NOT run these directly with `./target/debug/deno test` — they depend on thecargo test harness for correct setup.
02 / Good and bad pairs
A directory contains the command description, input files, and expected output. The example covers both a single command and a sequence of steps, making the custom test format concrete.
Source excerpt starting at line 198.1. Create a directory in `tests/specs/` with a descriptive name2. Add a `__test__.jsonc` file describing your test steps3. Add any input files needed for the test4. Add `.out` files for expected output (or inline in `__test__.jsonc`)
03 / House vocabulary
The guide distinguishes wildcards that span lines from those confined to one line, plus unordered blocks and literal character counts. These definitions help keep expectations specific around nondeterministic output.
Source excerpt starting at line 247.- `[WILDCARD]` : matches 0 or more of any character, like `.*` in regex. this can cross newlines- `[WILDLINE]` : matches 0 or more of any character, ending at the end of a line- `[WILDCHAR]` - match the next character- `[WILDCHARS(5)]` - match any of the next 5 characters- `[UNORDERED_START]` followed by many lines then `[UNORDERED_END]` will match the lines in any order (useful for non-deterministic output)- `[# example]` - line comments start with `[#` and end with `]`
04 / Verification by change type
Non-Rust changes use the JavaScript lint path. Rust changes require the full lint command, so verification follows the affected surface.
Source excerpt starting at line 29.- Before committing, if only non-Rust was changed, make sure to run `tools/lint.js --js` and fix any lint errors before committing
05 / Contribution etiquette
The no-force-push rule explains that changes will be squashed at merge and reviewers need to see follow-up commits. It gives a concrete reason to keep the branch history intact.
Source excerpt starting at line 35.- When pushing updates to the PR, make sure to never force push. Create as many commits as you need, all of them get squashed when the PR is merged, so there is no need to rewrite history. This also allows reviewers to see the incremental changes you made in response to feedback.
Put it to work
Deno's file tells an agent how the codebase works. It cannot tell it which bug three customers hit this week. Modem keeps that context current and attaches it to the work.
Try Modem