Deno.args: raw command-line arguments
Raw command-line arguments are available on Deno.args. For real tools, parse them with @std/cli/parse-args, which handles flags, options, and defaults.
cli/arguments
36 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Example: parseArgs from @std/cli
import { parseArgs } from "jsr:@std/cli/parse-args"; const flags = parseArgs(Deno.args, { string: ["name"], default: { name: "world" }, }); console.log(`Hello, ${flags.name}!`);
deno init creates a new project
Running 'deno init my_project' scaffolds a new project with deno.json for configuration, a main.ts file, and main_test.ts for tests.
--allow-net flag enables network access
The -N flag (short form) or --allow-net (long form) grants code permission to access the network.
deno test runs built-in test runner
The 'deno test' command runs tests using Deno's built-in test runner. No additional test framework installation is required.
deno.json contains project configuration
The deno.json file holds project configuration including tasks, imports, dependency information, and tooling settings like lint and format configurations.
Built-in toolchain with fmt, lint, and task commands
Deno includes built-in commands for 'deno fmt' (formatting), 'deno lint' (linting), and 'deno task' (running scripts defined in deno.json). No additional tools need to be installed.
Node to Deno equivalents for run and watch
Node and Deno command equivalents for running code: node file.js is deno file.js, ts-node file.ts is deno file.ts, node -e "..." is deno eval "...", and nodemon is deno run --watch.
Node to Deno equivalents for quality and testing
Deno includes built-in tools with no install or config required: eslint is deno lint, prettier is deno fmt, jest/mocha/ava/tap is deno test, nyc/c8/istanbul is deno coverage, and benchmark libraries are deno bench.
Node to Deno equivalents for toolchain
Node and Deno toolchain equivalents: tsserver is deno lsp, and nvm/n/fnm is deno upgrade. Unlike nvm, deno upgrade updates the single installed binary and can pin any release (e.g., deno upgrade 2.1.0) without keeping multiple versions side by side.
deno task is the equivalent of bun run for scripts
Scripts defined in package.json can be run with deno task <script>, which is the Deno equivalent of bun run.
Bun to Deno CLI command equivalents
Dependencies: bun install → deno install, bun add <pkg> → deno add <pkg>, bun remove <pkg> → deno remove <pkg>, bun update → deno update, bun outdated → deno outdated. Run and execute: bun file.ts → deno file.ts, bun run <script> → deno task <script>, bunx <pkg> → dx <pkg>. Test, build, and toolchain: bun test → deno test, bun build → deno bundle, bun build --compile → deno compile, bun upgrade → deno upgrade.
deno fmt and deno lint cover formatter and linter functionality
Bun has no built-in formatter or linter. Deno's deno fmt and deno lint commands cover what would otherwise require installing Prettier, ESLint, or Biome with no extra dependencies.
Debug authentication tokens with deno run -L debug
Running deno run -L debug will print a debug message showing the number of tokens parsed from the DENO_AUTH_TOKENS environment variable. It will also print error messages if any tokens appear malformed, but will not print token details for security purposes.
--cached-only flag prevents network access
The `--cached-only` flag forbids the network entirely and fails if anything in the dependency tree is not already cached. This is useful for offline work and reproducible CI.
--reload flag for dependency cache
The `--reload` flag forces deno to refetch and recompile modules into the cache. `deno run --reload my_module.ts` reloads everything. `deno run --reload=jsr:@std/fs my_module.ts` reloads a specific module.
deno bump-version with Conventional Commits in workspaces
In a workspace, running deno bump-version with no increment derives each member's version bump from Conventional Commits made since the last release, rewrites jsr: constraints in the root import map so cross-package references stay in sync, and prepends a changelog entry to Releases.md.
deno publish command for JSR
deno publish type-checks code and verifies that exports don't rely on anything outside the package before uploading. Use deno publish --dry-run to verify the file list and metadata before publishing. The deno publish command opens jsr.io to authenticate, then publishes the package.
deno bump-version for version management
deno bump-version is used to bump the version field in deno.json between releases. It can also drive a whole workspace release by deriving each member's version bump from Conventional Commits made since the last release.
deno test --coverage collects coverage data into coverage/ directory
Pass --coverage when running tests with deno test. This writes raw coverage data into a coverage/ directory as one JSON profile per module. The data comes directly from the V8 JavaScript engine, which tracks execution as the code runs. Deno prints a coverage summary table after test results and writes an lcov.info file and an HTML report into the coverage directory.
deno test --coverage-raw-data-only excludes reports
Pass --coverage-raw-data-only to collect only raw coverage profiles without generating the coverage summary table, lcov.info file, or HTML report.
deno test --coverage accepts a directory argument
The --coverage flag can accept a value to specify a different directory for coverage data: deno test --coverage=cov_profile. Alternatively, set the DENO_COVERAGE_DIR environment variable to control the coverage directory.
deno test --clean empties coverage directory before tests
Pass --clean to empty the coverage directory before running tests. This prevents stale profiles from lingering and skewing the report when files are renamed or deleted.
deno run --coverage collects coverage data outside test runner
The deno run command accepts the same --coverage flag as deno test. This is useful for measuring code that does not run under the test runner, such as integration scripts, CLI invocations, or a server exercised from the outside.
Child Deno processes inherit DENO_COVERAGE_DIR environment variable
When tests spawn Deno subprocesses, set the DENO_COVERAGE_DIR environment variable. Child processes inherit this variable and their execution is collected into the same directory, appearing in the combined report.
deno coverage command generates coverage reports
The deno coverage command reads coverage data from a directory and generates a text report. Run it by pointing it at the coverage directory: deno coverage coverage/
Coverage report shows Branch %, Function %, and Line %
The coverage report displays three metrics for each file: Branch % (how many conditional paths were taken), Function % (how many declared functions were called at least once), and Line % (how many executable lines ran).
deno coverage --detailed shows uncovered lines
Pass --detailed to deno coverage to see which lines were missed. Uncovered lines are listed under each file with their line numbers.
deno coverage --html generates interactive HTML report
Pass --html to deno coverage to generate an HTML report written to coverage/html/. The report shows the summary table as a clickable file tree with each source file rendered line by line and uncovered code highlighted. Open coverage/html/index.html in a browser to explore it.
deno coverage --lcov exports coverage in lcov format
Pass --lcov to deno coverage to export coverage data in the lcov format, which is consumed by most coverage services and editor extensions. Use --output=coverage.lcov to write to a file, otherwise the lcov report is written to stdout.
deno coverage --include and --exclude filter files with regex
Use --include and --exclude with regex patterns to control which files appear in the coverage report. A file appears only if it matches the include pattern and does not match the exclude pattern. By default, the report includes local code and imports (URLs matching ^file:) and excludes files with test.js, test.mjs, test.ts, test.jsx, or test.tsx in their names.
Coverage ignore comments exclude code from coverage report
Mark code with coverage ignore comments to exclude it from the coverage report without failing the coverage check. Use // deno-coverage-ignore for a single line, // deno-coverage-ignore-start and // deno-coverage-ignore-stop for a block, or // deno-coverage-ignore-file at the top of a file to ignore the entire file. Every -start comment needs a matching -stop, and ranges cannot be nested.
Example: deno test --coverage with multiple options
Example showing coverage collection with the --clean flag to empty the directory first and the --allow-run permission: DENO_COVERAGE_DIR=cov_profile deno test --allow-run, followed by deno coverage cov_profile to generate the report.
Example: enforce coverage threshold with awk in CI
Shell script to enforce coverage threshold in CI: deno coverage --lcov coverage/ > coverage.lcov followed by awk -F: '/^LF/ {lf += $2} /^LH/ {lh += $2} END {pct = 100 * lh / lf; printf "line coverage: %.1f%%\n", pct; exit (pct < 80)}' coverage.lcov. The awk script exits non-zero when line coverage is below 80%, failing the CI step.
Manual CI pattern for Deno older versions
For older Deno versions or manual composition, the recommended CI install flow is: deno install --frozen --entrypoint main.ts (install dependencies exactly as locked; fail if drift or new deps), and optionally deno run --cached-only main.ts (run with only cached modules to guarantee no network access). If npm packages are present (package.json exists), include deno install or deno ci in CI before running tests to materialize the node_modules directory deterministically.
deno ci command
In Deno 2.8+, the deno ci command encapsulates the recommended CI install flow, including frozen lockfile and lifecycle scripts.