deno task basic purpose
deno task provides a cross-platform way to define and execute custom commands specific to a codebase. Tasks are defined in the deno.json configuration file under a "tasks" key.
Deno · Reference · all subjects
cli commands/task
42 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 task --if-present flag
The --if-present flag makes a task optional. When passed to deno task <name>, it exits with code 0 and prints nothing if the task is missing. This is useful for shared CI scripts that call a task only some packages define. The flag only suppresses the not-found case for the named task; listing tasks with bare deno task, running a task that does exist, and real errors such as a missing task dependency are unaffected.
deno task INIT_CWD environment variable
By default, deno task executes commands with the directory of the deno.json file as the current working directory. The INIT_CWD environment variable will be set with the full path to the directory the task was run in, if not already set. This allows tasks to change to the directory the user ran the task from and is aligned with npm run behavior. It works cross-platform including on Windows.
deno task wildcard pattern matching
The deno task command can run multiple tasks in parallel by passing a wildcard pattern specified with the * character. For example, deno task "build:*" will run all tasks matching that pattern. When using a wildcard, the task name must be quoted to prevent shell expansion. For multi-word task names, using : as the separator (e.g. build:client, test:unit, lint:fix) is recommended to match npm convention and to group related tasks for wildcard matching.
deno task wildcard exclusion pattern
Exclude tasks from a wildcard match by adding an exclusion group (!a|b|c) to the end of the pattern. Each listed value is matched against what the * captured. For example, deno task "test:*(!e2e|interactive)" runs test:unit and test:integration but skips test:e2e and test:interactive. A pattern that has an exclusion group but no * is rejected.
deno task --env-file flag
Pass --env-file to load variables from a dotenv file into the task's shell environment, so every command in the task body inherits them. For example, deno task --env-file start loads .env, or deno task --env-file=.env.production start loads a specific file. The flag can be given more than once to load multiple files, with later files taking precedence. With no value it defaults to .env.
deno task task dependencies
You can specify dependencies for a task by adding a "dependencies" field with an array of task names. When running a task with dependencies, the dependency tasks execute in parallel first, and once all of them finish successfully the main task executes. Dependency tasks are executed in parallel, with the default parallel limit being equal to the number of cores on your machine.
deno task --jobs and --concurrency flags for parallel execution
To change the parallel job limit for task dependencies, pass --jobs (short -j, also spelled --concurrency). For example, deno task --recursive --jobs 1 build runs workspace tasks fully sequentially. The DENO_JOBS environment variable can also set this for the environment, with the flag taking precedence.
deno task dependency deduplication
Dependencies are tracked in task execution. If multiple tasks depend on the same task, that task will only be run once. This applies to the entire dependency graph.
deno task cycle detection
If a cycle between task dependencies is discovered, an error will be returned. For example, if task a depends on b and task b depends on a, running deno task a will output: Task cycle detected: a -> b -> a
deno task dependencies without command
You can specify a task that has dependencies but no command. This is useful to logically group several tasks together. When such a task is run, only its dependency tasks execute in parallel.
deno task caching with files field
A task can skip work when none of its inputs have changed by adding a "files" field listing input globs. Deno fingerprints the command, appended arguments, contents of matching files, and values of any listed env vars, then skips the task on the next run when none changed. The "output" field lists globs the task produces, restoring them from cache on a cache hit. The "env" field lists environment variable names whose values are part of the cache key. Caching is opt-in: a task with no "files" field always runs. A task's dependency fingerprints are folded into its own cache key, so it re-runs whenever an upstream task did.
deno task npm and npx binary support
By default, deno task executes commands with the deno binary. To ensure a command runs with the npm or npx binary, invoke the npm or npx run command respectively. For example, a task with command "npm run test" will use npm.
deno task --recursive flag for workspaces
deno task can be used in workspaces to run tasks from multiple member directories in parallel. Use the --recursive flag to execute a task name from all workspace members. For example, deno task --recursive dev runs the dev task from all workspace members.
deno task --filter flag for workspace member filtering
Tasks to run in a workspace can be filtered based on the workspace members using the --filter flag. For example, deno task --filter "client" dev runs the dev task only for the workspace member with name "client" as specified in its deno.json name field.
deno task shell syntax: && operator
The && operator executes commands in sequence. If the first command succeeds (exits with code 0), the next command executes. If the first command fails, the next command does not execute.
deno task shell syntax: || operator
The || operator executes commands in sequence. If the first command fails (exits with non-zero code), the next command executes. If the first command succeeds, the next command does not execute.
deno task shell syntax: semicolon sequential lists
Commands separated with a semicolon (;) execute sequentially regardless of whether the previous command passed or failed. For example: deno run output_data.ts ; deno run --allow-net server.ts
deno task shell syntax: & async operator
Adding an & to the end of a command makes it execute asynchronously. For example, sleep 1 && deno run --allow-net server.ts & deno run --allow-net client.ts executes both the server and client at the same time. Unlike in most shells, the first async command to fail causes all other commands to fail immediately. You can opt out by adding || true to force a 0 exit code.
deno task shell syntax: export for environment variables
Environment variables are defined using the export command. For example: export VAR_NAME=value. Environment variables defined with export are exported to spawned commands. Shell variable substitution works with $VAR syntax.
deno task shell syntax: setting environment variables for a command
To specify environment variable(s) before a command without exporting them globally, list them before the command. For example: VAR=hello VAR2=bye deno run main.ts. This sets those environment variables specifically for the following command only.
deno task shell syntax: shell variables without export
Shell variables are similar to environment variables but are not exported to spawned commands. They are defined with the syntax VAR_NAME=value without the export keyword. Shell variables can be useful when reusing a value but not wanting it available in any spawned processes.
deno task shell syntax: $? exit status variable
The exit code of the previously run command is available in the $? variable. For example: deno eval 'Deno.exit(10)' || echo $? outputs 10
deno task shell syntax: pipelines with |
Pipelines provide a way to pipe stdout of one command to stdin of another using the | operator. For example: echo Hello | deno run main.ts pipes the stdout output to the spawned Deno process.
deno task shell syntax: |& for piping stdout and stderr
Use |& instead of | to pipe both stdout and stderr of one command to another. For example: deno eval 'console.log(1); console.error(2);' |& deno run main.ts pipes both stdout and stderr.
deno task shell syntax: command substitution with $()
The $(command) syntax provides a way to use the output of a command in other commands. For example: deno run main.ts $(git rev-parse HEAD) substitutes the output of git rev-parse HEAD into the command.
deno task shell syntax: negate exit code with !
To negate the exit code of a command, add an exclamation point and space before it. For example: ! deno eval 'Deno.exit(1);' changes the exit code from 1 to 0.
deno task shell syntax: suppress output with /dev/null
Suppress stdout, stderr, or both of a command by redirecting to /dev/null. This works cross-platform including on Windows. Examples: deno run main.ts > /dev/null (suppress stdout), deno run main.ts 2> /dev/null (suppress stderr), deno run main.ts &> /dev/null (suppress both).
deno task shell syntax: redirect stdout to stderr and vice versa
Redirect stdout to stderr using >&2. Redirect stderr to stdout using 2>&1. For example: deno run main.ts >&2 redirects stdout to stderr, and deno run main.ts 2>&1 redirects stderr to stdout.
deno task shell syntax: input redirects
Input redirects are supported using <. For example: gzip < file.txt redirects file.txt to the stdin of gzip. Note that redirecting multiple redirects is currently not supported.
deno task cross-platform shebang support
Starting in Deno 1.42, deno task executes scripts that start with #!/usr/bin/env -S the same way on all platforms. For example, a script file with #!/usr/bin/env -S deno run at the top can be referenced as a task command like "hi": "./script.ts" and will execute on Windows the same way as on Mac or Linux.
deno task glob expansion
Glob expansion is supported in Deno 1.34 and above in a cross-platform way. Supported glob characters are *, ?, and [/]. Examples: **/*.ts matches .ts files in current and descendant directories, *.ts matches .ts files in the current directory, data[0-9].csv matches files that start with "data", have a single number, then end with .csv.
deno task globstar default behavior
By default in deno task, globstar is enabled, so ** recurses into all descendant directories including node_modules. This differs from some interactive shells where ** is not recursive unless explicitly enabled. A task like deno check **/*.ts can expand to far more files than the same command in your terminal, potentially causing errors like "Argument list too long" or type-checking unintended dependency files.
deno task shell options configuration
deno task supports shell options in Deno 2.6.6 and above. By default, failglob and globstar are enabled. Options can be controlled with shopt and set commands within tasks. Supported options: failglob (globs that don't match cause error; disable with shopt -u failglob), globstar (** matches zero or more directories; disable with shopt -u globstar), nullglob (globs that don't match expand to nothing instead of literal pattern; enable with shopt -s nullglob), pipefail (pipeline exit code is from last non-zero command or zero if all succeed; enable with set -o pipefail), errexit (sequential list aborts on first non-zero exit; enable with set -e or set -o errexit; available in Deno 2.8+).
deno task shell options non-propagation
Shell options do not propagate to deno task subprocesses. Each deno task invocation starts with the default options.
deno task built-in commands list
deno task ships with several built-in commands that work cross-platform on Windows, Mac, and Linux: cp (copies files), mv (moves files), rm (remove files or directories; ex. rm -rf [FILE]... to recursively delete), mkdir (makes directories; ex. mkdir -p DIRECTORY... to make directory and parents), pwd (prints current/working directory), sleep (delays for specified time; ex. sleep 1 for 1 second, sleep 0.5 for half second, sleep 1m for minute), echo (displays line of text), cat (concatenates files and outputs on stdout; reads stdin when no arguments), exit (causes shell to exit), head (output first part of file), export (sets and exports environment variables to spawned commands), unset (unsets environment variables), xargs (builds arguments from stdin and executes command), : (POSIX null command; does nothing and always exits with status 0; available in Deno 2.8+; handy as no-op placeholder in conditionals).
deno task built-in commands non-cross-platform execution
To execute any of the built-in deno task commands in a non-cross-platform way on Mac or Linux, run it through sh: sh -c <command> (ex. sh -c cp source destination).
deno task package.json fallback
deno task falls back to reading from the "scripts" entries in a package.json file if it is discovered. Deno does not respect or support npm lifecycle events like preinstall or postinstall—you must explicitly run the script entries you want (ex. deno install --entrypoint main.ts && deno task postinstall).
deno task npm environment variables for package.json scripts
When deno task runs a package.json script, it sets npm_* environment variables that npm exposes, so scripts that read them keep working. These include npm_package_name, npm_package_version, npm_lifecycle_event (the script name), npm_lifecycle_script (its command string), npm_config_user_agent, npm_execpath (path of running deno executable), npm_node_execpath (path of running deno executable), and npm_command (set to run-script). These variables are set only for package.json scripts. Tasks defined in deno.json do not receive them.
deno task command resolution order
When a task command references a binary (e.g. ohm, tsc, eslint), Deno resolves it using the following order: 1) node_modules/.bin/ - if the task's directory or a parent directory has a node_modules/.bin/ folder, Deno looks there first (note: deno add npm:<pkg> updates deno.json imports and deno.lock but does not create node_modules; it's only created when using deno install or npm-compatible tooling); 2) package.json bin field - when a dependency defines a bin field in its package.json, Deno automatically makes those commands available within task scripts through its npm compatibility layer; 3) System PATH - if not found above, Deno falls back to searching system PATH.
deno task task configuration format: string vs object
A task can be defined as a simple string command or as an object. The simple string format is: "taskname": "command string". The object format is: "taskname": { "command": "command string", "description": "optional description", "dependencies": [array of task names], "files": [array of input globs], "output": [array of output globs], "env": [array of env var names] }.
deno task parallel output prefixing (Deno 2.8+)
When tasks run in parallel in Deno 2.8+, each output line is prefixed with the task name that produced it (color-coded per task). Prefixes stay attached even when a task forks subprocesses, so a parallel build + test + lint run stays legible without an external multiplexer.