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)

Conversion failures

Since Nash 0.8.1, an unreadable or malformed .vscode/tasks.json, or one with an unsupported format version, is logged and ignored. Your Nash tasks remain available; a foreign task file does not replace the whole task palette with an error. Nash accepts version "2.0.0" or an omitted version.

If the file parses but an individual task cannot be expressed in Nash, only that task is skipped. Examples include an unsupported task type, a missing dependsOn target, or a dependency cycle. Other convertible tasks still appear. Check Nash's log for the skipped task's label and the reason.

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.cwd → cwd

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

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

cwd = "packages/cli"

options.env → env

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.executable → shell

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:

Value	Nash 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).