deno-lint-ignore directive silences a specific rule
To silence a rule for one line, add a comment with // deno-lint-ignore rule-name above the line in question. The rule name must match exactly.
cli/lint
24 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
deno lint command lints TypeScript and JavaScript files
The deno lint command analyzes all TypeScript and JavaScript files in the current directory and its subdirectories by default. To lint specific files or directories, pass them as arguments: deno lint src/
deno lint --fix applies automatic fixes
Some lint rules can fix problems automatically. Running deno lint --fix will apply those fixes to files.
ESLint can be run via deno run npm:eslint
ESLint can be run without a global installation using deno run -A npm:eslint . ESLint requires a flat config file named eslint.config.js. Reference npm packages with npm: specifiers so Deno can resolve them. Include Node and Deno globals in the config to prevent false no-undef errors for globals such as console.
oxlint can be run via deno run npm:oxlint
oxlint is a fast Rust-based linter that can be run with deno run -A npm:oxlint@latest. It requires no configuration and lints the current directory, printing any problems found.
ESLint with TypeScript requires typescript-eslint plugin
For type-aware linting of TypeScript files with ESLint, add typescript-eslint to the eslint.config.js configuration.
ESLint extension requires nodeModulesDir auto for VS Code
The VS Code ESLint extension needs a real node_modules directory to resolve ESLint and its plugins. Set "nodeModulesDir": "auto" in deno.json and run deno install so the packages are materialized on disk.
deno test --doc command
The deno test --doc command extracts code examples from JSDoc comments and markdown files and runs them as tests. This keeps documentation examples current: when APIs change, outdated examples fail in CI instead of misleading readers.
Supported language identifiers for doc test code blocks
Code blocks in JSDoc comments and markdown files can use the following language identifiers: js, javascript, mjs, cjs, jsx, ts, typescript, mts, cts, tsx. If no language identifier is specified, the language is inferred from the media type of the source document.
Exported items automatically imported in doc tests
When running deno test --doc, any items exported from the documented module are automatically included in the generated test code using import statements. The user does not need to manually import exported functions, constants, or default exports from the module being documented.
Doc test code generation adds imports
When deno test --doc extracts a code block from a JSDoc comment, it automatically generates an import statement for all exported items from the module, then wraps the code block in a Deno.test() call. For example, a code block at lines 4-10 becomes a test case named 'example.ts$4-10.ts'.
Hashbang and permission flags in doc test code blocks
If a code example starts with a hashbang (#!/usr/bin/env -S deno run ...), the permission flags in that hashbang are validated against supported Deno CLI flags and forwarded to the generated Deno.test() call. A code example never runs with broader permissions than what deno test was granted, even if the hashbang specifies broader ones.
Permission flag interpretation in doc test hashbangs
Permission flags in doc test hashbangs are interpreted as follows: --allow-all inherits all permissions from deno test; --allow-* inherits the specified permission from deno test; --allow-*=… restricts the specified permission to provided values; --deny-* explicitly revokes the specified permission; --deny-*=… is currently unsupported (results in test failure); --permission-set is currently unsupported (ignored); --ignore-* is currently unsupported (ignored); no permission flags means no permissions.
Skipping doc test code blocks with ignore attribute
You can prevent a code block from being evaluated by adding the 'ignore' attribute to the code block marker, such as ```ts ignore. This is useful for code examples that should not be run as tests.
deno check --doc for type-checking without running doc tests
Use deno check --doc to type-check code snippets in JSDoc comments without actually running them. Use deno check --doc-only to type-check markdown files only.
deno doc documentation linting error codes
The three named error codes from 'deno doc --lint' are: 'missing-jsdoc', 'missing-return-type', and 'private-type-ref'. These can be used with grep or in tooling to filter specific error types.
deno lint command
deno lint runs the linter on Deno projects.
ban-unknown-rule-code lint rule
The ban-unknown-rule-code lint rule is recommended and warns about the usage of unknown rule codes in ignore directives. It checks that rule names specified in deno-lint-ignore comments are valid and provided by deno_lint.
deno-lint-ignore directive syntax
Use deno-lint-ignore followed by one or more rule names to suppress lint errors. Rule names are space-separated. Example: // deno-lint-ignore no-explicit-any no-unused-vars
deno-lint-ignore invalid example with typo
A typo in a rule name like eq-eq-e (instead of eq-eq-eq) will be caught by ban-unknown-rule-code and is invalid.
deno-lint-ignore invalid example with unknown rule
Using an unknown rule name like UNKNOWN_RULE_NAME in a deno-lint-ignore directive is invalid and will be caught by ban-unknown-rule-code.
deno-lint-ignore valid example eq-eq-eq
The rule name eq-eq-eq is valid when used in a deno-lint-ignore directive to suppress the eq-eq-eq lint rule.
deno-lint-ignore valid example no-unused-vars
The rule name no-unused-vars is valid when used in a deno-lint-ignore directive to suppress the no-unused-vars lint rule.
no-deprecated-deno-api lint rule
The no-deprecated-deno-api lint rule warns about usage of deprecated Deno APIs. It is a recommended rule.