VSCode Task Conversion Details

This page covers the exact conversion semantics when nash ingests a tasks.json file.

Recognition

Nash looks for tasks.json files in the following locations, in priority order:

  1. <project>/.vscode/tasks.json — workspace-level tasks
  2. <project>/.vscode/tasks/*.json — task fragments (if supported)

Type Mapping

type: "shell"

The task's command string is executed through the system shell, equivalent to nash's command field.

// tasks.json { "label": "Start Server", "type": "shell", "command": "npx vite --port 4173" }
# .nash.toml equivalent [[task]] id = "start-server" title = "Start Server" command = "npx vite --port 4173"

type: "process"

The command and args are launched directly without shell interpretation, equivalent to nash's argv field.

// tasks.json { "label": "Lint", "type": "process", "command": "eslint", "args": [".", "--max-warnings=0"] }
# .nash.toml equivalent [[task]] id = "lint" title = "Lint" argv = ["eslint", ".", "--max-warnings=0"]

Options

options.cwdcwd

Sets the working directory for the task. Relative paths resolve from the workspace root.

{ "options": { "cwd": "${workspaceFolder}/packages/cli" } }
cwd = "packages/cli"

options.envenv

Environment variables are mapped directly to nash's env table.

{ "options": { "env": { "NODE_ENV": "production", "DEBUG": "true" } } }
[env] NODE_ENV = "production" DEBUG = "true"

options.shell.executableshell

Overrides the default shell used for execution.

{ "options": { "shell": { "executable": "/bin/zsh", "args": ["-l", "-c"] } } }
shell = ["/bin/zsh", "-l", "-c"]

Presentation & Behavior

presentation.panel

Controls whether the task output panel is shared or dedicated:

ValueNash Equivalent
"shared"keep = false
"dedicated"keep = true
"new"keep = true

group

Task groups from VS Code are preserved for palette organization but do not affect nash's grouping, which is based on section and subsection in the TOML hierarchy.

problemMatcher

Nash does not use VS Code's problem matchers directly. When a problemMatcher is present, nash adds the task label with a ⚠️ icon in the palette as a hint that the task may have diagnostic output.

Unsupported VS Code Fields

The following VS Code task features have no direct nash equivalent and are silently ignored during conversion:

  • detail — use description in nash
  • isBackground — use keep = true to prevent closing
  • dependsOn — define multi-step tasks using [[task.step]] instead
  • runOptions.reevaluateOnRerun — not applicable
  • runOptions.runOn — not applicable

Priority Rules

When both tasks.json and .nash.toml define a task with the same effective id:

  1. Native nash tasks in .nash.toml take full precedence
  2. tasks.json fields not overridden by nash are still inherited
  3. Environment variables from both sources are merged, with nash values winning on conflict
# .nash.toml [[task]] id = "build" title = "Build (with extras)" env = { PROFILE = "release" }
// tasks.json { "label": "Build", "type": "shell", "command": "npm run build", "options": { "env": { "NODE_ENV": "production" } } }

Result: The task runs with title "Build (with extras)", command from tasks.json, and merges both PROFILE=release (nash priority) and NODE_ENV=production (from VS Code).