작업을 통한 외부 도구와의 통합

소프트웨어 시스템의 린트, 빌드, 패키징, 테스트 또는 배포와 같은 작업을 자동화하는 데는 많은 도구가 있습니다. 예를 들어 TypeScript 컴파일러, ESLint 및 TSLint와 같은 린터, Make, Ant, Gulp, Jake, Rake 및 MSBuild와 같은 빌드 시스템이 있습니다.

이러한 도구는 대부분 명령줄에서 실행되며 소프트웨어 개발의 내부 루프(편집, 컴파일, 테스트, 디버그) 안팎에서 작업을 자동화합니다. 개발 수명 주기에서 이러한 도구의 중요성을 고려할 때 VS Code 내에서 도구를 실행하고 결과를 분석할 수 있으면 유용합니다. VS Code의 작업은 스크립트를 실행하고 프로세스를 시작하도록 구성할 수 있으므로 기존 도구 중 상당수를 명령줄을 입력하거나 새 코드를 작성하지 않고도 VS Code 내에서 사용할 수 있습니다. 작업 영역 또는 폴더별 작업은 작업 영역의 .vscode 폴더에 있는 tasks.json 파일에서 구성됩니다.

확장 프로그램은 작업 제공자를 사용하여 작업을 제공할 수도 있으며, 이러한 제공된 작업은 tasks.json 파일에 정의된 작업 영역별 구성을 추가할 수 있습니다.

참고: 작업 지원은 작업 영역 폴더에서 작업할 때만 사용할 수 있습니다. 단일 파일을 편집할 때는 사용할 수 없습니다.

TypeScript Hello World

JavaScript로 컴파일하려는 간단한 "Hello World" TypeScript 프로그램으로 시작하겠습니다.

"mytask"라는 빈 폴더를 만들고 tsconfig.json 파일을 생성한 다음 해당 폴더에서 VS Code를 시작합니다.

mkdir mytask
cd mytask
tsc --init
code .

이제 다음 내용으로 HelloWorld.ts 파일을 만듭니다.

function sayHello(name: string): void {
  console.log(`Hello ${name}!`);
}

sayHello('Dave');

⇧⌘B (Windows, Linux Ctrl+Shift+B)를 누르거나 전역 **터미널** 메뉴에서 **빌드 작업 실행**을 실행하면 다음 피커가 표시됩니다.

첫 번째 항목은 TypeScript 컴파일러를 실행하고 TypeScript 파일을 JavaScript 파일로 변환합니다. 컴파일러가 완료되면 HelloWorld.js 파일이 있어야 합니다. 두 번째 항목은 watch 모드에서 TypeScript 컴파일러를 시작합니다. HelloWorld.ts 파일을 저장할 때마다 HelloWorld.js 파일이 다시 생성됩니다.

**빌드 작업 실행**(⇧⌘B (Windows, Linux Ctrl+Shift+B))을 트리거할 때 기본 빌드 작업으로 TypeScript 빌드 또는 watch 작업을 정의할 수도 있습니다. 그렇게 하려면 전역 **터미널** 메뉴에서 **기본 빌드 작업 구성**을 선택합니다. 그러면 사용 가능한 빌드 작업 목록이 표시됩니다. **tsc: build** 또는 **tsc: watch**를 선택하면 VS Code에서 tasks.json 파일을 생성합니다. 아래에 표시된 파일은 **tsc: build** 작업을 기본 빌드 작업으로 만듭니다.

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "type": "typescript",
      "tsconfig": "tsconfig.json",
      "problemMatcher": ["$tsc"],
      "group": {
        "kind": "build",
        "isDefault": true
      }
    }
  ]
}

위의 tasks.json 예시는 새 작업을 정의하지 않습니다. VS Code의 TypeScript 확장에서 제공하는 **tsc: build** 작업을 기본 빌드 작업으로 사용하도록 주석 처리합니다. 이제 ⇧⌘B (Windows, Linux Ctrl+Shift+B)를 눌러 TypeScript 컴파일러를 실행할 수 있습니다.

작업 자동 감지

VS Code는 현재 Gulp, Grunt, Jake 및 npm에 대해 작업을 자동 감지합니다. Maven 및 C# dotnet 명령에 대한 지원을 추가하기 위해 해당 확장 프로그램 작성자와 협력하고 있습니다. Node.js를 런타임으로 사용하는 JavaScript 애플리케이션을 개발하는 경우 일반적으로 종속성과 실행 스크립트를 설명하는 package.json 파일이 있습니다. eslint-starter 예제를 클론했다면 전역 메뉴에서 **작업 실행**을 실행하면 다음 목록이 표시됩니다.

아직 하지 않았다면 npm install을 실행하여 필요한 npm 모듈을 설치합니다. 이제 server.js 파일을 열고 문 끝에 세미콜론을 추가합니다(ESLint 스타터는 세미콜론이 없는 문을 가정합니다). 다시 **작업 실행**을 실행합니다. 이번에는 **npm: lint** 작업을 선택합니다. 문제 표시기 사용 여부를 묻는 메시지가 표시되면 **ESLint stylish**를 선택합니다.

작업을 실행하면 **문제** 보기에서 하나의 오류가 표시됩니다.

또한 VS Code는 다음과 같은 내용의 tasks.json 파일을 생성합니다.

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "type": "npm",
      "script": "lint",
      "problemMatcher": ["$eslint-stylish"]
    }
  ]
}

이것은 VS Code에 ESLint stylish 형식을 사용하여 **npm lint** 스크립트의 출력을 문제에 대해 스캔하도록 지시합니다.

Gulp, Grunt 및 Jake의 경우 작업 자동 감지는 동일하게 작동합니다. 아래는 vscode-node-debug 확장에서 감지된 작업 예제입니다.

**팁:** 'task'를 입력하고 Space, 그런 다음 명령 이름을 입력하여 **빠른 열기**(⌘P (Windows, Linux Ctrl+P))를 통해 작업을 실행할 수 있습니다. 이 경우 'task lint'입니다.

작업 자동 감지는 다음 설정을 사용하여 비활성화할 수 있습니다.

{
  "typescript.tsc.autoDetect": "off",
  "grunt.autoDetect": "off",
  "jake.autoDetect": "off",
  "gulp.autoDetect": "off",
  "npm.autoDetect": "off"
}

사용자 지정 작업

모든 작업이나 스크립트를 작업 영역에서 자동 감지할 수 있는 것은 아닙니다. 때로는 자체 사용자 지정 작업을 정의해야 할 수도 있습니다. 예를 들어 환경을 올바르게 설정하기 위해 테스트를 실행하는 스크립트가 있다고 가정해 보겠습니다. 이 스크립트는 작업 영역 내의 스크립트 폴더에 저장되며 Linux 및 macOS의 경우 test.sh, Windows의 경우 test.cmd로 명명됩니다. 전역 **터미널** 메뉴에서 **작업 구성**을 실행하고 **템플릿에서 tasks.json 파일 만들기** 항목을 선택합니다. 그러면 다음 피커가 열립니다.

참고: 작업 실행기 템플릿 목록이 표시되지 않으면 폴더에 이미 tasks.json 파일이 있고 내용이 편집기에 열려 있을 수 있습니다. 파일을 닫고 이 예제를 위해 파일을 삭제하거나 이름을 바꾸세요.

더 많은 자동 감지 지원을 제공하기 위해 노력하고 있으므로 이 목록은 향후 점점 줄어들 것입니다. 자체 사용자 지정 작업을 작성하려고 하므로 목록에서 **기타**를 선택합니다. 그러면 작업 골격이 있는 tasks.json 파일이 열립니다. 내용을 다음으로 바꾸십시오.

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Run tests",
      "type": "shell",
      "command": "./scripts/test.sh",
      "windows": {
        "command": ".\\scripts\\test.cmd"
      },
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    }
  ]
}

작업의 속성은 다음과 같은 의미를 갖습니다.

• label: 사용자 인터페이스에 사용되는 작업의 레이블입니다.
• type: 작업의 유형입니다. 사용자 지정 작업의 경우 shell 또는 process가 될 수 있습니다. shell이 지정되면 명령은 셸 명령(예: bash, cmd 또는 PowerShell)으로 해석됩니다. process가 지정되면 명령은 실행할 프로세스로 해석됩니다.
• command: 실행할 실제 명령입니다.
• windows: Windows별 속성입니다. 명령이 Windows 운영 체제에서 실행될 때 기본 속성 대신 사용됩니다.
• group: 작업이 속하는 그룹을 정의합니다. 예제에서는 test 그룹에 속합니다. 테스트 그룹에 속하는 작업은 **명령 팔레트**에서 **테스트 작업 실행**을 실행하여 실행할 수 있습니다.
• presentation: 사용자 인터페이스에서 작업 출력이 처리되는 방식을 정의합니다. 이 예제에서는 출력을 표시하는 통합 터미널이 always로 표시되고 각 작업 실행 시 new 터미널이 생성됩니다.
• options: cwd(현재 작업 디렉토리), env(환경 변수) 또는 shell(기본 셸)의 기본값을 재정의합니다. 옵션은 작업별로 설정할 수 있지만 전역 또는 플랫폼별로 설정할 수도 있습니다. 여기에 구성된 환경 변수는 작업 스크립트 또는 프로세스 내에서만 참조할 수 있으며 args, 명령 또는 다른 작업 속성의 일부인 경우 확인되지 않습니다.
• runOptions: 작업이 실행되는 시점과 방법을 정의합니다.
• hide: 독립적으로 실행할 수 없는 복합 작업의 요소에 유용할 수 있는 실행 작업 빠른 선택에서 작업을 숨깁니다.

tasks.json 파일에서 IntelliSense를 사용하여 전체 작업 속성과 값을 볼 수 있습니다. **제안 트리거**(⌃Space (Windows, Linux Ctrl+Space))로 제안을 표시하고 마우스를 올리면 설명이 표시되거나 **자세히 보기...**('i') 플라이아웃을 사용합니다.

tasks.json 스키마도 검토할 수 있습니다.

공백이나 $와 같은 다른 특수 문자가 포함된 명령 및 인수의 경우 셸 명령은 특별한 처리가 필요합니다. 기본적으로 작업 시스템은 다음과 같은 동작을 지원합니다.

• 단일 명령이 제공되면 작업 시스템은 명령을 있는 그대로 기본 셸에 전달합니다. 명령이 제대로 작동하려면 따옴표나 이스케이프가 필요한 경우 명령에 올바른 따옴표 또는 이스케이프 문자가 포함되어야 합니다. 예를 들어 이름에 공백이 포함된 폴더의 디렉터리를 나열하려면 bash에서 실행되는 명령은 다음과 같아야 합니다. ls 'folder with spaces'.

{
  "label": "dir",
  "type": "shell",
  "command": "dir 'folder with spaces'"
}

• 명령과 인수가 제공되면 작업 시스템은 명령이나 인수에 공백이 포함된 경우 작은따옴표를 사용합니다. cmd.exe의 경우 큰따옴표가 사용됩니다. 아래와 같은 셸 명령은 PowerShell에서 dir 'folder with spaces'로 실행됩니다.

{
  "label": "dir",
  "type": "shell",
  "command": "dir",
  "args": ["folder with spaces"]
}

• 인수 인용 방법을 제어하려면 인수가 값과 인용 스타일을 지정하는 리터럴이 될 수 있습니다. 아래 예는 공백이 있는 인수에 대해 인용 대신 이스케이프를 사용합니다.

{
  "label": "dir",
  "type": "shell",
  "command": "dir",
  "args": [
    {
      "value": "folder with spaces",
      "quoting": "escape"
    }
  ]
}

이스케이프 외에도 다음 값이 지원됩니다.

• strong: 셸의 강력한 인용 메커니즘을 사용하며 문자열 안의 모든 평가를 억제합니다. PowerShell 및 Linux 및 macOS의 셸에서는 작은따옴표(')가 사용됩니다. cmd.exe의 경우 "가 사용됩니다.
• weak: 셸의 약한 인용 메커니즘을 사용하며 여전히 문자열 안의 식(예: 환경 변수)을 평가합니다. PowerShell 및 Linux 및 macOS의 셸에서는 큰따옴표(")가 사용됩니다. cmd.exe는 약한 인용을 지원하지 않으므로 VS Code도 "를 사용합니다.

명령 자체에 공백이 포함된 경우 VS Code는 기본적으로 명령도 강력하게 인용합니다. 인수와 마찬가지로 사용자는 동일한 리터럴 스타일을 사용하여 명령의 인용을 제어할 수 있습니다.

워크플로를 구성하는 데 더 많은 작업 속성이 있습니다. **제안 트리거**(⌃Space (Windows, Linux Ctrl+Space))를 사용하여 IntelliSense를 활용하면 유효한 속성 목록을 볼 수 있습니다.

전역 메뉴 표시줄 외에도 **명령 팔레트**(⇧⌘P (Windows, Linux Ctrl+Shift+P))를 사용하여 작업 명령에 액세스할 수 있습니다. 'task'로 필터링하면 다양한 작업 관련 명령을 볼 수 있습니다.

복합 작업

dependsOn 속성을 사용하여 간단한 작업으로 작업을 구성할 수도 있습니다. 예를 들어 클라이언트 폴더와 서버 폴더가 모두 있고 둘 다 빌드 스크립트를 포함하는 작업 영역이 있는 경우 별도의 터미널에서 두 빌드 스크립트를 모두 시작하는 작업을 만들 수 있습니다. dependsOn 속성에 여러 작업을 나열하면 기본적으로 병렬로 실행됩니다.

tasks.json 파일은 다음과 같습니다.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Client Build",
      "command": "gulp",
      "args": ["build"],
      "options": {
        "cwd": "${workspaceFolder}/client"
      }
    },
    {
      "label": "Server Build",
      "command": "gulp",
      "args": ["build"],
      "options": {
        "cwd": "${workspaceFolder}/server"
      }
    },
    {
      "label": "Build",
      "dependsOn": ["Client Build", "Server Build"]
    }
  ]
}

"dependsOrder": "sequence"를 지정하면 작업 종속성이 dependsOn에 나열된 순서대로 실행됩니다. "dependsOrder": "sequence"가 있는 dependsOn에서 사용되는 모든 백그라운드/watch 작업에는 해당 작업이 "완료"될 때까지 추적하는 문제 표시기가 있어야 합니다. 다음 작업은 작업 Two, 작업 Three, 그리고 작업 One을 실행합니다.

{
  "label": "One",
  "type": "shell",
  "command": "echo Hello ",
  "dependsOrder": "sequence",
  "dependsOn": ["Two", "Three"]
}

사용자 수준 작업

**작업: 사용자 작업 열기** 명령을 사용하여 특정 작업 영역 또는 폴더에 연결되지 않은 사용자 수준 작업을 만들 수 있습니다. 다른 작업 유형은 작업 영역 정보가 필요하므로 여기서는 shell 및 process 작업만 사용할 수 있습니다.

출력 동작

때로는 작업 실행 시 통합 터미널 패널의 동작을 제어하고 싶을 때가 있습니다. 예를 들어 편집기 공간을 최대화하고 문제가 있다고 생각하는 경우에만 작업 출력을 보려고 할 수 있습니다. 터미널의 동작은 작업의 presentation 속성을 사용하여 제어할 수 있습니다. 다음 속성을 제공합니다.

• reveal: 통합 터미널 패널이 맨 앞으로 가져와지는지 여부를 제어합니다. 유효한 값은 다음과 같습니다.
  • always - 패널은 항상 맨 앞으로 가져와집니다. 이것이 기본값입니다.
  • never - 사용자는 **보기** > **터미널** 명령(⌃` (Windows, Linux Ctrl+`))을 사용하여 명시적으로 터미널 패널을 맨 앞으로 가져와야 합니다.
  • silent - 오류 및 경고에 대해 출력이 스캔되지 않는 경우에만 터미널 패널이 맨 앞으로 가져와집니다.
• revealProblems: 이 작업을 실행할 때 문제 패널을 표시할지 여부를 제어합니다. reveal 옵션보다 우선합니다. 기본값은 never입니다.
  • always - 이 작업이 실행될 때 항상 문제 패널을 표시합니다.
  • onProblem - 문제가 발견된 경우에만 문제 패널을 표시합니다.
  • never - 이 작업이 실행될 때 문제 패널을 표시하지 않습니다.
• focus: 터미널이 입력 포커스를 취하는지 여부를 제어합니다. 기본값은 false입니다.
• echo: 실행 중인 명령이 터미널에 표시되는지 여부를 제어합니다. 기본값은 true입니다.
• showReuseMessage: "터미널은 작업에 의해 재사용되며, 닫으려면 아무 키나 누르십시오" 메시지를 표시할지 여부를 제어합니다.
• panel: 터미널 인스턴스가 작업 실행 간에 공유되는지 여부를 제어합니다. 가능한 값은 다음과 같습니다.
  • shared - 터미널이 공유되고 다른 작업 실행의 출력이 동일한 터미널에 추가됩니다.
  • dedicated - 터미널은 특정 작업에 전용됩니다. 해당 작업이 다시 실행되면 터미널이 재사용됩니다. 그러나 다른 작업의 출력은 다른 터미널에 표시됩니다.
  • new - 해당 작업의 모든 실행은 새 깨끗한 터미널을 사용합니다.
• clear: 이 작업이 실행되기 전에 터미널이 지워지는지 여부를 제어합니다. 기본값은 false입니다.
• close: 작업이 종료될 때 작업이 실행되는 터미널이 닫히는지 여부를 제어합니다. 기본값은 false입니다.
• group: 분할 창을 사용하여 특정 터미널 그룹에서 작업이 실행되는지 여부를 제어합니다. 동일한 그룹(문자열 값으로 지정)의 작업은 새 터미널 패널 대신 분할 터미널을 사용하여 표시됩니다.

자동 감지된 작업에 대해서도 터미널 패널 동작을 수정할 수 있습니다. 예를 들어 위 ESLint 예제의 **npm: run lint** 작업에 대한 출력 동작을 변경하려면 presentation 속성을 추가하십시오.

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "type": "npm",
      "script": "lint",
      "problemMatcher": ["$eslint-stylish"],
      "presentation": {
        "reveal": "never"
      }
    }
  ]
}

사용자 지정 작업을 감지된 작업에 대한 구성과 혼합할 수도 있습니다. **npm: run lint** 작업을 구성하고 사용자 지정 **Run Test** 작업을 추가하는 tasks.json은 다음과 같습니다.

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "type": "npm",
      "script": "lint",
      "problemMatcher": ["$eslint-stylish"],
      "presentation": {
        "reveal": "never"
      }
    },
    {
      "label": "Run tests",
      "type": "shell",
      "command": "./scripts/test.sh",
      "windows": {
        "command": ".\\scripts\\test.cmd"
      },
      "group": "test",
      "presentation": {
        "reveal": "always",
        "panel": "new"
      }
    }
  ]
}

실행 동작

runOptions 속성을 사용하여 작업의 실행 동작을 지정할 수 있습니다.

• reevaluateOnRerun: **마지막 작업 다시 실행** 명령을 통해 작업이 실행될 때 변수가 평가되는 방식을 제어합니다. 기본값은 true이며, 이는 작업이 다시 실행될 때 변수가 다시 평가됨을 의미합니다. false로 설정하면 작업의 이전 실행에서 해결된 변수 값이 사용됩니다.
• runOn: 작업이 실행되는 시점을 지정합니다.
  • default - 작업은 **작업 실행** 명령을 통해 실행될 때만 실행됩니다.
  • folderOpen - 해당 폴더가 열릴 때 작업이 실행됩니다. folderOpen이 포함된 폴더를 처음 열 때 해당 폴더에서 작업을 자동으로 실행하도록 허용할 것인지 묻는 메시지가 표시됩니다. **자동 작업 관리** 명령을 사용하여 나중에 **자동 작업 허용** 또는 **자동 작업 거부**를 선택하여 결정을 변경할 수 있습니다.
• instanceLimit - 동시에 실행할 수 있는 작업 인스턴스 수입니다. 기본값은 1입니다.

자동 감지된 작업 사용자 지정

앞서 언급했듯이 tasks.json 파일에서 자동 감지된 작업을 사용자 지정할 수 있습니다. 일반적으로 프레젠테이션 속성을 수정하거나 문제 표시기를 연결하여 작업 출력에서 오류 및 경고를 스캔하기 위해 그렇게 합니다. **작업 실행** 목록에서 기어 아이콘을 눌러 해당 작업 참조를 tasks.json 파일에 삽입하여 작업을 직접 사용자 지정할 수 있습니다. ESLint를 사용하여 JavaScript 파일을 린트하는 다음과 같은 Gulp 파일이 있다고 가정해 보겠습니다(파일은 https://github.com/adametry/gulp-eslint에서 가져옴).

const gulp = require('gulp');
const eslint = require('gulp-eslint');

gulp.task('lint', () => {
  // ESLint ignores files with "node_modules" paths.
  // So, it's best to have gulp ignore the directory as well.
  // Also, Be sure to return the stream from the task;
  // Otherwise, the task may end before the stream has finished.
  return (
    gulp
      .src(['**/*.js', '!node_modules/**'])
      // eslint() attaches the lint output to the "eslint" property
      // of the file object so it can be used by other modules.
      .pipe(eslint())
      // eslint.format() outputs the lint results to the console.
      // Alternatively use eslint.formatEach() (see Docs).
      .pipe(eslint.format())
      // To have the process exit with an error code (1) on
      // lint error, return the stream and pipe to failAfterError last.
      .pipe(eslint.failAfterError())
  );
});

gulp.task('default', ['lint'], function() {
  // This will only run if the lint task is successful...
});

전역 **터미널** 메뉴에서 **작업 실행**을 실행하면 다음 피커가 표시됩니다.

기어 아이콘을 누릅니다. 그러면 다음과 같은 tasks.json 파일이 생성됩니다.

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "type": "gulp",
      "task": "default",
      "problemMatcher": []
    }
  ]
}

일반적으로 여기서 문제 표시기(이 경우 $eslint-stylish)를 추가하거나 프레젠테이션 설정을 수정합니다.

문제 표시기를 사용하여 작업 출력 처리

VS Code는 문제 표시기를 사용하여 작업 출력을 처리할 수 있습니다. 문제 표시기는 작업 출력 텍스트에서 알려진 경고 또는 오류 문자열을 스캔하여 편집기와 문제 패널에 인라인으로 보고합니다. VS Code에는 '내장된' 몇 가지 문제 표시기가 있습니다.

• TypeScript: $tsc는 출력의 파일 이름이 열린 폴더를 기준으로 한다고 가정합니다.
• TypeScript Watch: $tsc-watch는 watch 모드에서 실행될 때 tsc 컴파일러에서 보고된 문제를 일치시킵니다.
• JSHint: $jshint는 파일 이름이 절대 경로로 보고된다고 가정합니다.
• JSHint Stylish: $jshint-stylish는 파일 이름이 절대 경로로 보고된다고 가정합니다.
• ESLint Compact: $eslint-compact는 출력의 파일 이름이 열린 폴더를 기준으로 한다고 가정합니다.
• ESLint Stylish: $eslint-stylish는 출력의 파일 이름이 열린 폴더를 기준으로 한다고 가정합니다.
• Go: $go는 go 컴파일러에서 보고된 문제를 일치시킵니다. 파일 이름이 열린 폴더를 기준으로 한다고 가정합니다.
• CSharp and VB Compiler: $mscompile는 파일 이름이 절대 경로로 보고된다고 가정합니다.
• Lessc compiler: $lessc는 파일 이름이 절대 경로로 보고된다고 가정합니다.
• Node Sass compiler: $node-sass는 파일 이름이 절대 경로로 보고된다고 가정합니다.

자체 문제 표시기를 만들 수도 있으며, 이는 나중 섹션에서 설명합니다.

작업에 키보드 바로 가기 키 바인딩

자주 실행해야 하는 작업이 있는 경우 작업에 대한 키보드 바로 가기 키를 정의할 수 있습니다.

예를 들어 위에서 **테스트 실행** 작업에 Ctrl+H를 바인딩하려면 keybindings.json 파일에 다음을 추가합니다.

{
  "key": "ctrl+h",
  "command": "workbench.action.tasks.runTask",
  "args": "Run tests"
}

변수 치환

작업 구성을 작성할 때 활성 파일(${file}) 또는 작업 영역 루트 폴더(${workspaceFolder})와 같은 미리 정의된 공통 변수 세트를 갖는 것이 유용합니다. VS Code는 tasks.json 파일의 문자열 내에서 변수 치환을 지원하며 미리 정의된 변수의 전체 목록은 변수 참조에서 볼 수 있습니다.

참고: 모든 속성이 변수 치환을 지원하는 것은 아닙니다. 특히 command, args 및 options만 변수 치환을 지원합니다.

다음은 활성 파일을 TypeScript 컴파일러에 전달하는 사용자 지정 작업 구성의 예입니다.

{
  "label": "TypeScript compile",
  "type": "shell",
  "command": "tsc ${file}",
  "problemMatcher": ["$tsc"]
}

마찬가지로 프로젝트의 구성 설정을 이름 앞에 ${config:를 붙여 참조할 수 있습니다. 예를 들어, ${config:python.formatting.autopep8Path}는 Python 확장 설정 formatting.autopep8Path를 반환합니다.

다음은 python.formatting.autopep8Path 설정에 정의된 autopep8 실행 파일을 사용하여 현재 파일에 autopep8을 실행하는 사용자 지정 작업 구성의 예입니다.

{
  "label": "autopep8 current file",
  "type": "process",
  "command": "${config:python.formatting.autopep8Path}",
  "args": ["--in-place", "${file}"]
}

tasks.json 또는 launch.json에 사용되는 선택한 Python 인터프리터를 지정하려면 ${command:python.interpreterPath} 명령을 사용할 수 있습니다.

간단한 변수 치환으로 충분하지 않은 경우 tasks.json 파일에 inputs 섹션을 추가하여 사용자로부터 입력을 받을 수도 있습니다.

inputs에 대한 자세한 내용은 변수 참조를 참조하십시오.

운영 체제별 속성

작업 시스템은 운영 체제별 값(예: 실행할 명령)을 정의하는 것을 지원합니다. 그렇게 하려면 tasks.json 파일에 운영 체제별 리터럴을 넣고 해당 리터럴 안에 해당 속성을 지정합니다.

다음은 Node.js 실행 파일을 명령으로 사용하고 Windows 및 Linux에서 다르게 처리되는 예입니다.

{
  "label": "Run Node",
  "type": "process",
  "windows": {
    "command": "C:\\Program Files\\nodejs\\node.exe"
  },
  "linux": {
    "command": "/usr/bin/node"
  }
}

유효한 운영 속성은 Windows의 경우 windows, Linux의 경우 linux, macOS의 경우 osx입니다. 운영 체제별 범위에 정의된 속성은 작업 또는 전역 범위에 정의된 속성을 재정의합니다.

전역 작업

작업 속성은 전역 범위에도 정의할 수 있습니다. 존재하는 경우 동일한 속성을 다른 값으로 정의하지 않는 한 특정 작업에 사용됩니다. 아래 예제에서는 모든 작업이 새 패널에서 실행되도록 정의하는 전역 presentation 속성이 있습니다.

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "presentation": {
    "panel": "new"
  },
  "tasks": [
    {
      "label": "TS - Compile current file",
      "type": "shell",
      "command": "tsc ${file}",
      "problemMatcher": ["$tsc"]
    }
  ]
}

팁: 전역 범위 tasks.json 파일에 액세스하려면 명령 팔레트(⇧⌘P (Windows, Linux Ctrl+Shift+P))를 열고 **작업: 사용자 작업 열기** 명령을 실행합니다.

PowerShell에서 문자 이스케이프

기본 셸이 PowerShell이거나 작업이 PowerShell을 사용하도록 구성된 경우 예상치 못한 공백 및 따옴표 이스케이프가 발생할 수 있습니다. VS Code는 명령에 cmdlet이 포함되어 있는지 알 수 없으므로 예상치 못한 이스케이프는 cmdlet에서만 발생합니다. 아래 예제 1은 PowerShell에서 작동하지 않는 이스케이프를 얻는 경우를 보여줍니다. 예제 2는 좋은, 플랫폼 간, 올바른 이스케이프를 얻는 가장 좋은 방법을 보여줍니다. 일부 경우에는 예제 2를 따를 수 없으며 예제 3에 표시된 수동 이스케이프를 수행해야 할 수 있습니다.

"tasks": [
    {
        "label": "PowerShell example 1 (unexpected escaping)",
        "type": "shell",
        "command": "Get-ChildItem \"Folder With Spaces\""
    },
    {
        "label": "PowerShell example 2 (expected escaping)",
        "type": "shell",
        "command": "Get-ChildItem",
        "args": ["Folder With Spaces"]
    },
    {
        "label": "PowerShell example 3 (manual escaping)",
        "type": "shell",
        "command": "& Get-ChildItem \\\"Folder With Spaces\\\""
    }
]

작업 출력의 인코딩 변경

작업은 종종 디스크의 파일과 함께 작동합니다. 이러한 파일이 시스템 인코딩과 다른 인코딩으로 디스크에 저장된 경우 작업으로 실행되는 명령에 어떤 인코딩을 사용할지 알려야 합니다. 이는 운영 체제 및 사용된 셸에 따라 달라지므로 이를 제어하는 ​​일반적인 솔루션은 없습니다. 아래에는 작동하도록 하는 조언과 예가 있습니다.

인코딩을 조정해야 하는 경우 운영 체제에서 사용하는 기본 인코딩을 변경하는 것이 합리적인지 확인하거나 셸의 프로필 파일을 조정하여 셸에 대한 인코딩을 변경하는 것이 좋습니다.

특정 작업에 대해서만 조정해야 하는 경우 인코딩을 변경하는 데 필요한 OS별 명령을 작업 명령줄에 추가하십시오. 다음 예는 코드 페이지 437을 기본값으로 사용하는 Windows에 대한 것입니다. 작업은 키릴 문자가 포함된 파일의 출력을 표시하므로 코드 페이지 866이 필요합니다. 파일 목록을 가져오는 작업은 기본 셸이 cmd.exe로 설정되어 있다고 가정하면 다음과 같습니다.

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "label": "more",
      "type": "shell",
      "command": "chcp 866 && more russian.txt",
      "problemMatcher": []
    }
  ]
}

작업이 PowerShell에서 실행되는 경우 명령은 chcp 866; more russian.txt와 같이 읽어야 합니다. Linux 및 macOS에서는 locale 명령을 사용하여 로캘을 검사하고 필요한 환경 변수를 조정할 수 있습니다.

작업 실행 예시

작업의 강력함을 강조하기 위해 VS Code가 린터 및 컴파일러와 같은 외부 도구를 통합하는 데 작업을 사용하는 몇 가지 예가 있습니다.

TypeScript를 JavaScript로 트랜스파일

TypeScript 주제에는 TypeScript를 JavaScript로 트랜스파일하고 VS Code 내에서 관련 오류를 관찰하는 작업을 만드는 예제가 포함되어 있습니다.

Less 및 SCSS를 CSS로 트랜스파일

CSS 주제는 CSS 파일을 생성하기 위해 작업을 사용하는 방법에 대한 예제를 제공합니다.

1. 빌드 작업을 사용하여 수동으로 트랜스파일
2. 파일 감시자를 사용한 컴파일 단계 자동화

문제 표시기 정의

VS Code에는 가장 일반적인 문제 표시기 중 일부가 '내장'되어 있습니다. 그러나 컴파일러와 린팅 도구가 많이 있으며, 각 도구는 자체 스타일의 오류와 경고를 생성하므로 자체 문제 표시기를 만들고 싶을 수 있습니다.

helloWorld.c 프로그램에서 개발자가 printf를 prinft로 오타했다고 가정해 보겠습니다. gcc로 컴파일하면 다음과 같은 경고가 발생합니다.

helloWorld.c:5:3: warning: implicit declaration of function ‘prinft’

출력에서 메시지를 캡처하고 VS Code에 해당 문제를 표시할 수 있는 문제 표시기를 만들고 싶습니다. 문제 표시기는 정규 표현식에 크게 의존합니다. 아래 섹션은 정규 표현식에 익숙하다고 가정합니다.

팁: ECMAScript(JavaScript) 플래버를 가진 RegEx101 플레이그라운드는 정규 표현식을 개발하고 테스트하는 데 훌륭한 방법을 제공한다고 생각합니다.

위의 경고(및 오류)를 캡처하는 표시기는 다음과 같습니다.

{
  // The problem is owned by the cpp language service.
  "owner": "cpp",
  // The file name for reported problems is relative to the opened folder.
  "fileLocation": ["relative", "${workspaceFolder}"],
  // The name that will be shown as the source of the problem.
  "source": "gcc",
  // The actual pattern to match problems in the output.
  "pattern": {
    // The regular expression. Example to match: helloWorld.c:5:3: warning: implicit declaration of function ‘printf’ [-Wimplicit-function-declaration]
    "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
    // The first match group matches the file name which is relative.
    "file": 1,
    // The second match group matches the line on which the problem occurred.
    "line": 2,
    // The third match group matches the column at which the problem occurred.
    "column": 3,
    // The fourth match group matches the problem's severity. Can be ignored. Then all problems are captured as errors.
    "severity": 4,
    // The fifth match group matches the message.
    "message": 5
  }
}

파일, 줄 및 메시지 속성은 필수임을 유의하십시오. fileLocation은 작업 출력에서 생성되고 문제에서 일치되는 파일 경로가 absolute인지 relative인지 지정합니다. 작업이 절대 및 상대 경로를 모두 생성하는 경우 autoDetect 파일 위치를 사용할 수 있습니다. autoDetect를 사용하면 경로가 먼저 절대 경로로 테스트되고, 파일이 존재하지 않으면 해당 경로가 상대 경로로 가정됩니다.

severity는 패턴에 포함되지 않은 경우 사용할 문제 심각도를 지정합니다. severity의 가능한 값은 error, warning 또는 info입니다.

다음은 위 코드를 포함하는 완료된 tasks.json 파일입니다(주석 제거됨). 실제 작업 세부 정보로 래핑되어 있습니다.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "build",
      "command": "gcc",
      "args": ["-Wall", "helloWorld.c", "-o", "helloWorld"],
      "problemMatcher": {
        "owner": "cpp",
        "fileLocation": ["relative", "${workspaceFolder}"],
        "source": "gcc",
        "pattern": {
          "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
          "file": 1,
          "line": 2,
          "column": 3,
          "severity": 4,
          "message": 5
        }
      }
    }
  ]
}

VS Code 내에서 실행하고 **문제**(⇧⌘M (Windows, Linux Ctrl+Shift+M))를 눌러 문제 목록을 얻으면 다음과 같은 출력이 표시됩니다.

참고: C/C++ 확장에는 GCC용 문제 표시기가 포함되어 있으므로 자체를 정의할 필요가 없습니다.

패턴 내에서 사용할 수 있는 몇 가지 속성이 더 있습니다. 이들은 다음과 같습니다.

• location - 문제 위치가 line 또는 line,column 또는 startLine,startColumn,endLine,endColumn인 경우 범용 위치 일치 그룹을 사용할 수 있습니다.
• endLine - 문제의 끝 줄에 대한 일치 그룹 인덱스입니다. 컴파일러에서 끝 줄 값이 제공되지 않으면 생략할 수 있습니다.
• endColumn - 문제의 끝 열에 대한 일치 그룹 인덱스입니다. 컴파일러에서 끝 열 값이 제공되지 않으면 생략할 수 있습니다.
• code - 문제 코드에 대한 일치 그룹 인덱스입니다. 컴파일러에서 코드 값이 제공되지 않으면 생략할 수 있습니다.

패턴에 kind 속성을 file로 설정하여 파일만 캡처하는 문제 표시기를 정의할 수도 있습니다. 이 경우 line 또는 location 속성을 제공할 필요가 없습니다.

참고: kind 속성이 file로 설정된 경우, 함수 패턴은 최소한 file 및 message에 대한 일치 그룹을 제공해야 합니다. kind 속성이 제공되지 않거나 kind 속성이 location으로 설정된 경우, 함수 패턴은 line 또는 location 속성도 제공해야 합니다.

참고: 문제 검사기는 제공된 명령의 출력만 파싱합니다. 별도의 파일(예: 로그 파일)에 기록된 출력을 파싱하려면 실행하는 명령이 완료되기 전에 별도의 파일에서 줄을 출력하도록 하세요.

여러 줄 문제 표시기 정의

일부 도구는 특히 스타일리시한 보고서를 사용할 때 소스 파일에서 발견된 문제를 여러 줄에 걸쳐 분산시킵니다. 한 가지 예는 ESLint입니다. 스타일리시 모드에서는 다음과 같은 출력을 생성합니다.

test.js
  1:0   error  Missing "use strict" statement                 strict
✖ 1 problems (1 errors, 0 warnings)

당사의 문제 검사기는 줄 기반이므로 실제 문제 위치 및 메시지(1:0 오류 "use strict" 문 누락)와 다른 정규 표현식으로 파일 이름(test.js)을 캡처해야 합니다.

이를 위해 pattern 속성에 대한 문제 패턴 배열을 사용하세요. 이 방법으로 일치시키려는 각 줄마다 패턴을 정의할 수 있습니다.

다음 문제 패턴은 스타일리시 모드에서 ESLint의 출력을 일치시키지만, 다음 단계에서 해결해야 할 한 가지 작은 문제가 여전히 있습니다. 아래 코드는 파일 이름을 캡처하기 위한 첫 번째 정규 표현식과 줄, 열, 심각도, 메시지 및 오류 코드를 캡처하기 위한 두 번째 정규 표현식을 가지고 있습니다.

{
  "owner": "javascript",
  "fileLocation": ["relative", "${workspaceFolder}"],
  "pattern": [
    {
      "regexp": "^([^\\s].*)$",
      "file": 1
    },
    {
      "regexp": "^\\s+(\\d+):(\\d+)\\s+(error|warning|info)\\s+(.*)\\s\\s+(.*)$",
      "line": 1,
      "column": 2,
      "severity": 3,
      "message": 4,
      "code": 5
    }
  ]
}

그러나 이 패턴은 리소스에 문제가 하나 이상 있는 경우 작동하지 않습니다. 예를 들어 ESLint의 다음 출력을 상상해 보세요.

test.js
  1:0   error  Missing "use strict" statement                 strict
  1:9   error  foo is defined but never used                  no-unused-vars
  2:5   error  x is defined but never used                    no-unused-vars
  2:11  error  Missing semicolon                              semi
  3:1   error  "bar" is not defined                           no-undef
  4:1   error  Newline required at end of file but not found  eol-last
✖ 6 problems (6 errors, 0 warnings)

패턴의 첫 번째 정규 표현식은 "test.js"를 일치시키고, 두 번째 정규 표현식은 "1:0 오류..."를 일치시킵니다. 다음 줄 "1:9 오류..."가 처리되지만 첫 번째 정규 표현식과 일치하지 않아 문제가 캡처되지 않습니다.

이것이 작동하도록 하려면 여러 줄 패턴의 마지막 정규 표현식이 loop 속성을 지정할 수 있습니다. true로 설정하면 작업 시스템은 정규 표현식이 일치하는 한 여러 줄 검사기의 마지막 패턴을 출력의 줄에 적용하도록 지시합니다.

첫 번째 패턴(이 경우 test.js와 일치)에 의해 캡처된 정보는 loop 패턴과 일치하는 후속 각 줄과 결합되어 여러 문제를 생성합니다. 이 예에서는 여섯 개의 문제가 생성됩니다.

ESLint 스타일리시 문제를 완전히 캡처하기 위한 문제 검사기는 다음과 같습니다.

{
  "owner": "javascript",
  "fileLocation": ["relative", "${workspaceFolder}"],
  "pattern": [
    {
      "regexp": "^([^\\s].*)$",
      "file": 1
    },
    {
      "regexp": "^\\s+(\\d+):(\\d+)\\s+(error|warning|info)\\s+(.*)\\s\\s+(.*)$",
      "line": 1,
      "column": 2,
      "severity": 3,
      "message": 4,
      "code": 5,
      "loop": true
    }
  ]
}

참고: 동일한 리소스에서 정확히 동일한 줄과 열에 발생하는 여러 문제가 있는 경우 하나의 문제만 표시됩니다. 이는 여러 줄 문제 검사기뿐만 아니라 모든 문제 검사기에 적용됩니다.

기존 문제 표시기 수정

기존 문제 검사기가 필요한 것과 거의 일치하는 경우 tasks.json 작업에서 수정할 수 있습니다. 예를 들어 $tsc-watch 문제 검사기는 닫힌 문서에만 적용됩니다. 모든 문서에 적용되도록 하려면 수정할 수 있습니다.

{
  "type": "npm",
  "script": "watch",
  "problemMatcher": {
    "base": "$tsc-watch",
    "applyTo": "allDocuments"
  },
  "isBackground": true
}

수정 가능한 다른 문제 검사기 속성에는 background, fileLocation, owner, pattern, severity 및 source가 있습니다.

백그라운드 / 감시 작업

일부 도구는 백그라운드에서 실행하면서 파일 시스템 변경 사항을 감시하고 디스크에서 파일이 변경될 때 작업을 트리거하는 기능을 지원합니다. Gulp의 경우 이러한 기능은 npm 모듈 gulp-watch를 통해 제공됩니다. TypeScript 컴파일러 tsc는 --watch 명령줄 옵션을 통해 이에 대한 내장 지원을 제공합니다.

백그라운드 작업이 VS Code에서 활성 상태이고 문제 결과를 생성하고 있음을 피드백하려면 문제 검사기가 출력에서 이러한 state 변경을 감지하기 위해 추가 정보를 사용해야 합니다. tsc 컴파일러를 예로 들어 보겠습니다. 컴파일러가 watch 모드로 시작되면 콘솔에 다음과 같은 추가 정보가 출력됩니다.

> tsc --watch
12:30:36 PM - Compilation complete. Watching for file changes.

디스크에서 문제가 포함된 파일이 변경되면 다음과 같은 출력이 나타납니다.

12:32:35 PM - File change detected. Starting incremental compilation...
src/messages.ts(276,9): error TS2304: Cannot find name 'candidate'.
12:32:35 PM - Compilation complete. Watching for file changes.

출력을 보면 다음과 같은 패턴을 알 수 있습니다.

• 컴파일러는 File change detected. Starting incremental compilation...이 콘솔에 출력될 때 실행됩니다.
• 컴파일러는 Compilation complete. Watching for file changes.가 콘솔에 출력될 때 중지됩니다.
• 이 두 문자열 사이에서 문제가 보고됩니다.
• 컴파일러는 초기 시작 시(File change detected. Starting incremental compilation...을 콘솔에 출력하지 않음)에도 한 번 실행됩니다.

이 정보를 캡처하기 위해 문제 검사기는 background 속성을 제공할 수 있습니다.

tsc 컴파일러의 경우 적절한 background 속성은 다음과 같습니다.

"background": {
    "activeOnStart": true,
    "beginsPattern": "^\\s*\\d{1,2}:\\d{1,2}:\\d{1,2}(?: AM| PM)? - File change detected\\. Starting incremental compilation\\.\\.\\.",
    "endsPattern": "^\\s*\\d{1,2}:\\d{1,2}:\\d{1,2}(?: AM| PM)? - Compilation complete\\. Watching for file changes\\."
}

문제 검사기의 background 속성 외에도 작업 자체가 isBackground로 표시되어야 작업이 백그라운드에서 계속 실행됩니다.

watch 모드에서 실행되는 tsc 작업을 위한 전체 수동 tasks.json은 다음과 같습니다.

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "watch",
      "command": "tsc",
      "args": ["--watch"],
      "isBackground": true,
      "problemMatcher": {
        "owner": "typescript",
        "fileLocation": "relative",
        "pattern": {
          "regexp": "^([^\\s].*)\\((\\d+|\\d+,\\d+|\\d+,\\d+,\\d+,\\d+)\\):\\s+(error|warning|info)\\s+(TS\\d+)\\s*:\\s*(.*)$",
          "file": 1,
          "location": 2,
          "severity": 3,
          "code": 4,
          "message": 5
        },
        "background": {
          "activeOnStart": true,
          "beginsPattern": "^\\s*\\d{1,2}:\\d{1,2}:\\d{1,2}(?: AM| PM)? - File change detected\\. Starting incremental compilation\\.\\.\\.",
          "endsPattern": "^\\s*\\d{1,2}:\\d{1,2}:\\d{1,2}(?: AM| PM)? - Compilation complete\\. Watching for file changes\\."
        }
      }
    }
  ]
}

다음 단계

지금까지 작업에 대해 설명했습니다. 계속 진행하겠습니다...

• tasks.json 스키마 - 전체 tasks.json 스키마와 설명을 검토할 수 있습니다.
• 기본 편집 - 강력한 VS Code 편집기에 대해 알아보세요.
• 코드 탐색 - 소스 코드를 빠르게 이동합니다.
• 언어 지원 - VS Code에 포함된 지원 프로그래밍 언어와 커뮤니티 확장 프로그램을 통해 지원되는 언어에 대해 알아보세요.
• 디버깅 - VS Code 편집기에서 소스 코드를 직접 디버그하세요.

자주 묻는 질문

작업에서 통합 터미널에 대해 지정된 것과 다른 셸을 사용할 수 있습니까?

예. "terminal.integrated.automationProfile.*" 설정을 사용하여 VS Code의 모든 자동화에 사용될 셸을 설정할 수 있으며, 여기에는 작업이 포함됩니다.

    "terminal.integrated.automationProfile.windows": {
        "path": "cmd.exe"
    }

또는 options.shell 속성을 사용하여 작업의 셸을 재정의할 수 있습니다. 작업별, 전역별 또는 플랫폼별로 설정할 수 있습니다. 예를 들어 Windows에서 cmd.exe를 사용하려면 tasks.json에 다음이 포함됩니다.

{
    "version": "2.0.0",
    "windows": {
        "options": {
            "shell": {
                "executable": "cmd.exe",
                "args": [
                    "/d", "/c"
                ]
            }
        }
    },
    ...

백그라운드 작업은 launch.json에서 prelaunchTask로 사용할 수 있습니까?

예. 백그라운드 작업은 종료될 때까지 실행되므로 백그라운드 작업 자체에는 "완료"되었다는 신호가 없습니다. 백그라운드 작업을 prelaunchTask로 사용하려면 백그라운드 작업에 적절한 백그라운드 problemMatcher를 추가하여 작업 시스템과 디버그 시스템이 작업이 "완료"되었음을 알 수 있는 방법을 제공해야 합니다.

작업은 다음과 같을 수 있습니다.

{
  "type": "npm",
  "script": "watch",
  "problemMatcher": "$tsc-watch",
  "isBackground": true
}

참고: $tsc-watch는 백그라운드 작업에 필요한 백그라운드 문제 검사기입니다.

그런 다음 launch.json 파일에서 작업을 prelaunchTask로 사용할 수 있습니다.

{
  "name": "Launch Extension",
  "type": "extensionHost",
  "request": "launch",
  "runtimeExecutable": "${execPath}",
  "args": ["--extensionDevelopmentPath=${workspaceRoot}"],
  "stopOnEntry": false,
  "sourceMaps": true,
  "outFiles": ["${workspaceRoot}/out/src/**/*.js"],
  "preLaunchTask": "npm: watch"
}

백그라운드 작업에 대한 자세한 내용은 백그라운드 / 감시 작업으로 이동하세요.

작업을 실행할 때 "명령을 찾을 수 없습니다" 오류가 발생하는 이유는 무엇입니까?

"명령을 찾을 수 없습니다" 메시지는 실행하려는 작업 명령을 터미널에서 실행 가능한 것으로 인식하지 못할 때 발생합니다. 가장 흔한 이유는 명령이 셸의 시작 스크립트의 일부로 구성되어 있기 때문입니다. 작업은 비로그인 및 비대화형으로 실행되므로 셸의 시작 스크립트가 실행되지 않습니다. 특히 nvm은 구성의 일부로 시작 스크립트를 사용하는 것으로 알려져 있습니다.

이 문제를 해결하는 몇 가지 방법이 있습니다.

1. 명령이 경로에 있는지 확인하고 경로에 추가하기 위해 시작 스크립트를 필요로 하지 않는지 확인하세요. 이것이 문제를 해결하는 가장 철저한 방법이며 권장되는 해결책입니다.
2. 작업을 로그인 또는 대화형으로 실행하기 위한 일회성 수정 사항을 만들 수 있습니다. 이는 다른 결과를 초래할 수 있으므로 권장되지 않습니다. 그러나 단일 작업에 대한 빠르고 쉬운 수정이 될 수도 있습니다. 아래는 bash를 셸로 사용하여 이 작업을 수행하는 예입니다.

{
  "type": "npm",
  "script": "watch",
  "options": {
    "shell": {
      "args": ["-c", "-l"]
    }
  }
}

위의 npm 작업은 작업 시스템이 기본적으로 수행하는 것과 마찬가지로 명령(-c)과 함께 bash를 실행합니다. 그러나 이 작업은 bash를 로그인 셸(-l)로도 실행합니다.