Scope & Overrides

Nash tasks can originate from multiple sources. Understanding the merge behavior is key to managing tasks across your workflow.

Task Sources

Tasks are loaded in the following order, with later sources overriding earlier ones:

1. Global — tasks.toml in your nash configuration directory
2. Project — .nash.toml in the current project root
3. VS Code — tasks.json from a .vscode/ folder (auto-converted)

Merge Rules

When the same id appears in multiple sources:

• Project entries replace global entries with the same id

• VS Code–converted entries follow the same override logic

• Entries with different ids from each source are all available

#  tasks.toml (global)
[[task]]
id = "build"
title = "Build (Global)"
command = "make"

#  .nash.toml (project)
[[task]]
id = "build"
title = "Build (Project)"
command = "cargo build --release"

In this example, running the "Build" task uses the project-level definition (cargo build --release), while the global version is completely replaced.

VS Code Task Conversion

Nash can consume VS Code's tasks.json and make those tasks available in the nash command palette. Conversion applies the following mapping:

VS Code Field	Nash Equivalent
label	title
type	Used to determine execution strategy
command	command (shell) or argv (process)
args	Appended to command or argv
options.cwd	cwd
options.env	env
presentation.panel	Influences keep behavior

When both native nash tasks and VS Code tasks exist, nash merges them by id/label, with native definitions taking precedence when they match.

Practical Example

A typical project setup might look like:

# ~/.config/nash/tasks.toml — personal defaults
version = 1

[[task]]
id = "lint"
title = "Lint"
command = "eslint . --max-warnings=0"

[[task]]
id = "test"
title = "Run Tests"
command = "jest --no-coverage"

# /my-project/.nash.toml — project overrides
version = 1

[[task]]
id = "test"
title = "Run Tests"
command = "jest --no-coverage --testPathPattern='src'"
env = { CI = "false" }

[[task]]
id = "deploy-staging"
title = "Deploy to Staging"
target = "new_tab"
command = "scripts/deploy.sh staging"

Here the global lint task is inherited as-is, while the test task is overridden with a project-specific variant. The deploy-staging task is only available within the project.