VS Code에서 Node.js 디버깅
Visual Studio Code 편집기에는 Node.js 런타임에 대한 내장 디버깅 지원이 있으며 JavaScript, TypeScript 및 JavaScript로 변환되는 다른 많은 언어를 디버깅할 수 있습니다. VS Code는 적절한 실행 구성 기본값 및 스니펫을 제공하여 Node.js 디버깅 프로젝트 설정을 간단하게 할 수 있습니다.
VS Code에서 Node.js 프로그램을 디버깅하는 몇 가지 방법이 있습니다.
- VS Code의 통합 터미널에서 실행하는 프로세스를 디버깅하려면 자동 연결을 사용하세요.
- 통합 터미널을 사용하는 것과 유사하게 JavaScript 디버그 터미널을 사용하세요.
- 프로그램을 시작하려면 실행 구성을 사용하거나 VS Code 외부에서 시작된 프로세스에 연결하세요.
자동 연결
자동 연결 기능이 활성화된 경우, Node 디버거는 VS Code의 통합 터미널에서 시작된 특정 Node.js 프로세스에 자동으로 연결됩니다. 기능을 활성화하려면 명령 팔레트(⇧⌘P (Windows, Linux Ctrl+Shift+P))에서 자동 연결 토글 명령을 사용하거나, 이미 활성화된 경우 상태 표시줄의 자동 연결 항목을 사용하세요.
자동 연결에는 세 가지 모드가 있으며, 결과 빠른 선택 메뉴와 debug.javascript.autoAttachFilter 설정을 통해 선택할 수 있습니다.
smart-node_modules폴더 외부의 스크립트를 실행하거나 mocha 또는 ts-node와 같은 일반적인 '러너' 스크립트를 사용하는 경우 프로세스가 디버깅됩니다. 자동 연결 스마트 패턴 설정(debug.javascript.autoAttachSmartPattern)을 사용하여 '러너' 스크립트 허용 목록을 구성할 수 있습니다.always- 통합 터미널에서 시작된 모든 Node.js 프로세스가 디버깅됩니다.onlyWithFlag---inspect또는--inspect-brk플래그로 시작된 프로세스만 디버깅됩니다.
자동 연결을 활성화한 후에는 터미널 오른쪽 상단의 ⚠ 아이콘을 클릭하여 터미널을 다시 시작하거나 새 터미널을 만들면 됩니다. 그러면 디버거가 1초 안에 프로그램에 연결됩니다.
자동 연결이 켜져 있으면 VS Code 창 하단의 상태 표시줄에 자동 연결 항목이 표시됩니다. 이 항목을 클릭하면 자동 연결 모드를 변경하거나 임시로 비활성화할 수 있습니다. 자동 연결을 임시로 비활성화하는 것은 디버깅이 필요 없는 일회성 프로그램을 실행 중이지만 기능을 완전히 비활성화하고 싶지 않을 때 유용합니다.
추가 구성
기타 실행 구성 속성
debug.javascript.terminalOptions 설정에서 launch.json에 일반적으로 포함되는 다른 속성을 자동 연결에 적용할 수 있습니다. 예를 들어, skipFiles에 노드 내부를 추가하려면 사용자 또는 작업 영역 설정에 다음을 추가할 수 있습니다.
"debug.javascript.terminalOptions": {
"skipFiles": [
"<node_internals>/**"
]
},
자동 연결 스마트 패턴
smart 자동 연결 모드에서 VS Code는 사용자가 디버깅하려는 빌드 도구가 아닌 코드에 연결하려고 시도합니다. 이는 기본 스크립트를 Glob 패턴 목록과 일치시켜 수행합니다. Glob 패턴은 debug.javascript.autoAttachSmartPattern 설정에서 구성할 수 있으며 기본값은 다음과 같습니다.
[
'!**/node_modules/**', // exclude scripts in node_modules folders
'**/$KNOWN_TOOLS$/**' // but include some common tools
];
$KNOWN_TOOLS$는 ts-node, mocha, ava 등과 같은 일반적인 '코드 러너' 목록으로 대체됩니다. 이러한 설정이 작동하지 않으면 이 목록을 수정할 수 있습니다. 예를 들어, mocha를 제외하고 my-cool-test-runner를 포함하려면 두 줄을 추가할 수 있습니다.
[
'!**/node_modules/**',
'**/$KNOWN_TOOLS$/**',
'!**/node_modules/mocha/**', // use "!" to exclude all scripts in "mocha" node modules
'**/node_modules/my-cool-test-runner/**' // include scripts in the custom test runner
];
JavaScript 디버그 터미널
자동 연결과 유사하게, JavaScript 디버그 터미널은 해당 터미널에서 실행되는 모든 Node.js 프로세스를 자동으로 디버깅합니다. 명령 팔레트(kbs(workbench.action.showCommands))에서 디버그: JavaScript 디버그 터미널 만들기 명령을 실행하거나 터미널 선택 드롭다운에서 JavaScript 디버그 터미널 만들기를 선택하여 디버그 터미널을 만들 수 있습니다.
추가 구성
기타 실행 구성 속성
debug.javascript.terminalOptions 설정에서 launch.json에 일반적으로 포함되는 다른 속성을 디버그 터미널에 적용할 수 있습니다. 예를 들어, skipFiles에 노드 내부를 추가하려면 사용자 또는 작업 영역 설정에 다음을 추가할 수 있습니다.
"debug.javascript.terminalOptions": {
"skipFiles": [
"<node_internals>/**"
]
},
실행 구성
실행 구성은 VS Code에서 디버깅을 설정하는 전통적인 방법이며 복잡한 애플리케이션 실행을 위한 가장 많은 구성 옵션을 제공합니다.
이 섹션에서는 고급 디버깅 시나리오를 위한 구성 및 기능에 대해 자세히 설명합니다. 소스 맵을 사용한 디버깅, 외부 코드 건너뛰기, 원격 디버깅 등에 대한 지침을 찾을 수 있습니다.
소개 비디오를 시청하려면 VS Code 디버깅 시작하기를 참조하세요.
참고: VS Code를 처음 사용하는 경우, 디버깅 주제에서 일반 디버깅 기능 및
launch.json구성 파일 만들기에 대해 알아볼 수 있습니다.
실행 구성 속성
디버깅 구성은 작업 영역의 .vscode 폴더에 있는 launch.json 파일에 저장됩니다. 디버깅 구성 파일 생성 및 사용에 대한 소개는 일반 디버깅 문서에 있습니다.
아래는 Node.js 디버거에 특정한 일반적인 launch.json 속성에 대한 참조입니다. 전체 옵션 세트는 vscode-js-debug 옵션 설명서에서 볼 수 있습니다.
다음 속성은 요청 유형 launch 및 attach의 실행 구성에서 지원됩니다.
outFiles- 생성된 JavaScript 파일을 찾는 Glob 패턴 배열입니다. 소스 맵 섹션을 참조하세요.resolveSourceMapLocations- 소스 맵을 구문 분석할 위치에 대한 Glob 패턴 배열입니다. 소스 맵 섹션을 참조하세요.timeout- 세션을 다시 시작할 때 이 시간(밀리초) 후에 타임아웃됩니다. Node.js에 연결 섹션을 참조하세요.stopOnEntry- 프로그램 시작 시 즉시 중단합니다.localRoot- VS Code의 루트 디렉터리입니다. 원격 디버깅 섹션을 참조하세요.remoteRoot- Node.js의 루트 디렉터리입니다. 원격 디버깅 섹션을 참조하세요.smartStep- 소스 파일에 매핑되지 않는 코드를 자동으로 건너뛰려고 시도합니다. 스마트 단계 섹션을 참조하세요.skipFiles- 이 Glob 패턴으로 처리되는 파일을 자동으로 건너뜁니다. 불필요한 코드 건너뛰기 섹션을 참조하세요.trace- 진단 출력을 활성화합니다.
이 속성은 요청 유형 launch의 실행 구성에서만 사용할 수 있습니다.
program- 디버그할 Node.js 프로그램의 절대 경로입니다.args- 디버그할 프로그램에 전달되는 인수입니다. 이 속성은 배열 유형이며 개별 인수를 배열 요소로 예상합니다.cwd- 디버그할 프로그램을 실행할 디렉터리입니다.runtimeExecutable- 사용할 런타임 실행 파일의 절대 경로입니다. 기본값은node입니다. npm 및 기타 도구에 대한 실행 구성 지원 섹션을 참조하세요.runtimeArgs- 런타임 실행 파일에 전달되는 선택적 인수입니다.runtimeVersion- Node.js 버전을 관리하기 위해 "nvm"(또는 "nvm-windows") 또는 "nvs"를 사용하는 경우, 이 속성을 사용하여 특정 버전의 Node.js를 선택할 수 있습니다. 다중 버전 지원 섹션을 참조하세요.env- 선택적 환경 변수입니다. 이 속성은 문자열 형식의 키/값 쌍 목록으로 환경 변수를 예상합니다.envFile- 환경 변수 정의가 포함된 파일의 선택적 경로입니다. 외부 파일에서 환경 변수 로드 섹션을 참조하세요.console- 프로그램을 실행할 콘솔(internalConsole,integratedTerminal,externalTerminal)입니다. Node 콘솔 섹션을 참조하세요.outputCapture-std로 설정하면 디버그 포트를 통해 출력을 수신하는 대신 프로세스 stdout/stderr의 출력이 디버그 콘솔에 표시됩니다. 이는console.*API를 사용하지 않고 stdout/stderr 스트림에 직접 쓰는 프로그램 또는 로그 라이브러리에 유용합니다.
이 속성은 요청 유형 attach의 실행 구성에서만 사용할 수 있습니다.
restart- 종료 시 연결을 다시 시작합니다. 디버그 세션 자동 다시 시작 섹션을 참조하세요.port- 사용할 디버그 포트입니다. Node.js에 연결 및 원격 디버깅 섹션을 참조하세요.address- 디버그 포트의 TCP/IP 주소입니다. Node.js에 연결 및 원격 디버깅 섹션을 참조하세요.processId- 디버거는 USR1 신호를 보낸 후 이 프로세스에 연결하려고 시도합니다. 이 설정을 사용하면 디버그 모드로 시작되지 않은 이미 실행 중인 프로세스에 디버거를 연결할 수 있습니다.processId속성을 사용할 때 디버그 포트는 Node.js 버전(및 사용된 프로토콜)을 기반으로 자동으로 결정되며 명시적으로 구성할 수 없습니다. 따라서port속성을 지정하지 마십시오.continueOnAttach- 연결 시 프로세스가 일시 중지된 경우 계속할지 여부입니다. 이 옵션은--inspect-brk로 프로그램을 시작하는 경우 유용합니다.
일반적인 시나리오를 위한 실행 구성
launch.json 파일에서 IntelliSense(⌃Space (Windows, Linux Ctrl+Space))를 트리거하여 일반적으로 사용되는 Node.js 디버깅 시나리오에 대한 실행 구성 스니펫을 볼 수 있습니다.
launch.json 편집기 창의 오른쪽 하단에 있는 구성 추가... 버튼을 사용하여 스니펫을 가져올 수도 있습니다.
다음 스니펫을 사용할 수 있습니다.
- 프로그램 실행: Node.js 프로그램을 디버그 모드로 실행합니다.
- npm을 통해 실행: npm 'debug' 스크립트를 통해 Node.js 프로그램을 실행합니다. package.json에 정의된 경우 실행 구성에서 npm 디버그 스크립트를 사용할 수 있습니다. npm 스크립트에서 사용되는 디버그 포트는 스니펫에 지정된 포트와 일치해야 합니다.
- 연결: 로컬에서 실행 중인 Node.js 프로그램의 디버그 포트에 연결합니다. 디버그할 Node.js 프로그램이 디버그 모드로 시작되었고 사용된 디버그 포트가 스니펫에 지정된 것과 동일한지 확인하세요.
- 원격 프로그램에 연결:
address속성에 지정된 호스트에서 실행 중인 Node.js 프로그램의 디버그 포트에 연결합니다. 디버그할 Node.js 프로그램이 디버그 모드로 시작되었고 사용된 디버그 포트가 스니펫에 지정된 것과 동일한지 확인하세요. VS Code가 작업 영역과 원격 호스트의 파일 시스템 간의 소스 파일을 매핑하는 데 도움이 되도록localRoot및remoteRoot속성에 대해 올바른 경로를 지정하세요. - 프로세스 ID로 연결: 프로세스 선택기를 열어 디버깅할 노드 또는 gulp 프로세스를 선택합니다. 이 실행 구성을 사용하면 디버그 모드로 시작되지 않은 노드 또는 gulp 프로세스에도 연결할 수 있습니다.
- Nodemon 설정: JavaScript 소스가 변경될 때마다 디버그 세션을 자동으로 다시 시작하려면 nodemon을 사용합니다. nodemon이 전역적으로 설치되어 있는지 확인하세요. 디버그 세션을 종료해도 nodemon 자체는 종료되지 않습니다. nodemon을 종료하려면 통합 터미널에서 Ctrl+C를 누르세요.
- Mocha 테스트: 프로젝트의
test폴더에서 mocha 테스트를 디버깅합니다. 프로젝트에node_modules폴더에 'mocha'가 설치되어 있는지 확인하세요. - Yeoman 생성기: yeoman 생성기를 디버깅합니다. 스니펫은 생성기 이름을 지정하도록 요청합니다. 프로젝트에
node_modules폴더에 'yo'가 설치되어 있고 생성된 프로젝트가 프로젝트 폴더에서npm link를 실행하여 디버깅을 위해 설치되었는지 확인하세요. - Gulp 작업: gulp 작업을 디버깅합니다. 프로젝트에
node_modules폴더에 'gulp'가 설치되어 있는지 확인하세요. - Electron 메인: Electron 애플리케이션의 메인 Node.js 프로세스를 디버깅합니다. 스니펫은 Electron 실행 파일이 작업 영역의
node_modules/.bin디렉터리 내에 설치되었다고 가정합니다.
Node 콘솔
기본적으로 Node.js 디버그 세션은 VS Code 내부 디버그 콘솔에서 대상을 시작합니다. 디버그 콘솔은 콘솔에서 입력을 읽어야 하는 프로그램을 지원하지 않으므로, 실행 구성에서 console 속성을 externalTerminal 또는 integratedTerminal로 설정하여 외부 터미널을 활성화하거나 VS Code 통합 터미널을 사용할 수 있습니다. 기본값은 internalConsole입니다.
외부 터미널에서 terminal.external.windowsExec, terminal.external.osxExec, terminal.external.linuxExec 설정을 통해 사용할 터미널 프로그램을 구성할 수 있습니다.
npm 및 기타 도구에 대한 실행 구성 지원
Node.js 프로그램을 직접 node로 실행하는 대신, 실행 구성에서 직접 'npm' 스크립트 또는 다른 작업 러너 도구를 사용할 수 있습니다.
- PATH에서 사용 가능한 모든 프로그램(예: 'npm', 'mocha', 'gulp' 등)을
runtimeExecutable속성에 사용하고,runtimeArgs를 통해 인수를 전달할 수 있습니다. - npm 스크립트 또는 다른 도구가 실행할 프로그램을 암시적으로 지정하는 경우
program속성을 설정할 필요가 없습니다.
'npm' 예제를 살펴보겠습니다. package.json에 'debug' 스크립트가 있는 경우, 예를 들어
"scripts": {
"debug": "node myProgram.js"
},
해당 실행 구성은 다음과 같이 표시됩니다.
{
"name": "Launch via npm",
"type": "node",
"request": "launch",
"cwd": "${workspaceFolder}",
"runtimeExecutable": "npm",
"runtimeArgs": ["run-script", "debug"]
}
다중 버전 지원
Node.js 버전을 관리하기 위해 'nvm'(또는 'nvm-windows')을 사용하는 경우, 특정 버전의 Node.js를 선택하기 위해 실행 구성에 runtimeVersion 속성을 지정할 수 있습니다.
{
"type": "node",
"request": "launch",
"name": "Launch test",
"runtimeVersion": "14",
"program": "${workspaceFolder}/test.js"
}
Node.js 버전을 관리하기 위해 'nvs'를 사용하는 경우, runtimeVersion 속성을 사용하여 특정 버전, 아키텍처 및 플레이버 Node.js를 선택할 수 있습니다. 예를 들어
{
"type": "node",
"request": "launch",
"name": "Launch test",
"runtimeVersion": "chackracore/8.9.4/x64",
"program": "${workspaceFolder}/test.js"
}
runtimeVersion 속성과 함께 사용하려는 Node.js 버전을 설치했는지 확인하세요. 이 기능은 버전을 자동으로 다운로드하여 설치하지 않습니다. 예를 들어, "runtimeVersion": "7.10.1"을 실행 구성에 추가하려면 통합 터미널에서 nvm install 7.10.1 또는 nvs add 7.10.1과 같은 명령을 실행해야 합니다.
부 버전과 패치 버전을 생략하고 예를 들어 "runtimeVersion": "14"와 같이 설정하면 시스템에 설치된 가장 최신 14.x.y 버전이 사용됩니다.
외부 파일에서 환경 변수 로드
VS Code Node 디버거는 환경 변수를 파일에서 로드하여 Node.js 런타임에 전달하는 것을 지원합니다. 이 기능을 사용하려면 실행 구성에 envFile 속성을 추가하고 환경 변수가 포함된 파일의 절대 경로를 지정하세요.
//...
"envFile": "${workspaceFolder}/.env",
"env": { "USER": "john doe" }
//...
env 딕셔너리에 지정된 모든 환경 변수는 파일에서 로드된 변수를 재정의합니다.
.env 파일의 예는 다음과 같습니다.
USER=doe
PASSWORD=abc123
# a comment
# an empty value:
empty=
# new lines expanded in quoted strings:
lines="foo\nbar"
Node.js에 연결
VS Code 디버거를 외부 Node.js 프로그램에 연결하려면 다음과 같이 Node.js를 실행하세요.
node --inspect program.js
또는 프로그램이 실행되지 않고 디버거가 연결될 때까지 기다려야 하는 경우:
node --inspect-brk program.js
프로그램에 디버거를 연결하는 옵션
- 잠재적인 후보 프로세스 목록을 표시하고 하나를 선택할 수 있는 "프로세스 선택기"를 열거나,
- 명시적으로 모든 구성 옵션을 지정하는 "연결" 구성을 만든 다음 F5를 누르세요.
이 옵션들을 자세히 살펴보겠습니다.
Node 프로세스 연결 작업
명령 팔레트(⇧⌘P (Windows, Linux Ctrl+Shift+P))의 Node 프로세스 연결 명령은 Node.js 디버거에서 사용할 수 있는 모든 잠재적 프로세스 목록을 표시하는 빠른 선택 메뉴를 엽니다.
선택기 목록에 표시되는 개별 프로세스는 디버그 포트와 프로세스 ID를 보여줍니다. 목록에서 Node.js 프로세스를 선택하면 Node.js 디버거가 해당 프로세스에 연결을 시도합니다.
Node.js 프로세스 외에도 선택기는 다양한 형태의 --inspect 인수로 시작된 다른 프로그램도 표시합니다. 이를 통해 Electron 또는 VS Code의 도우미 프로세스에 연결할 수 있습니다.
"연결" 구성 설정
이 옵션은 더 많은 작업이 필요하지만 이전 두 옵션과 달리 다양한 디버그 구성 옵션을 명시적으로 구성할 수 있습니다.
가장 간단한 "연결" 구성은 다음과 같습니다.
{
"name": "Attach to Process",
"type": "node",
"request": "attach",
"port": 9229
}
포트 9229는 --inspect 및 --inspect-brk 옵션의 기본 디버그 포트입니다. 다른 포트(예: 12345)를 사용하려면 옵션에 --inspect=12345 및 --inspect-brk=12345를 추가하고 실행 구성의 port 속성을 일치하도록 변경하세요.
디버그 모드로 시작되지 않은 Node.js 프로세스에 연결하려면 프로세스 ID를 문자열로 지정하여 수행할 수 있습니다.
{
"name": "Attach to Process",
"type": "node",
"request": "attach",
"processId": "53426"
}
실행 구성에 새 프로세스 ID를 반복해서 입력하는 것을 피하기 위해 Node 디버그는 프로세스 선택기(위 참조)를 여는 명령 변수 PickProcess를 지원합니다.
PickProcess 변수를 사용한 실행 구성은 다음과 같습니다.
{
"name": "Attach to Process",
"type": "node",
"request": "attach",
"processId": "${command:PickProcess}"
}
디버깅 중지
디버그 도구 모음 또는 명령 팔레트에서 사용할 수 있는 디버그: 중지 작업을 사용하면 디버그 세션이 중지됩니다.
"연결" 모드에서 디버그 세션이 시작된 경우(디버그 도구 모음의 빨간색 종료 버튼에 겹쳐진 "플러그" 아이콘이 표시됨), 중지를 누르면 Node.js 디버거가 디버깅 대상에서 분리되고 그러면 실행이 계속됩니다.
디버그 세션이 "실행" 모드인 경우, 중지를 누르면 다음이 수행됩니다.
-
빨간색 중지 버튼을 처음 누르면 디버깅 대상에
SIGINT신호를 보내 정상적으로 종료하도록 요청합니다. 디버깅 대상은 이 신호를 가로채고 필요한 정리 작업을 수행한 다음 종료할 수 있습니다. 해당 종료 코드에 중단점(또는 문제가 없음)이 없으면 디버깅 대상과 디버그 세션이 종료됩니다. -
그러나 디버거가 종료 코드의 중단점에 도달하거나 디버깅 대상이 자체적으로 제대로 종료되지 않으면 디버그 세션이 종료되지 않습니다. 이 경우, 중지를 다시 누르면 디버깅 대상과 해당 자식 프로세스가 강제로 종료됩니다(
SIGKILL).
빨간색 중지 버튼을 눌렀을 때 디버그 세션이 종료되지 않는 것을 보면, 디버깅 대상을 강제 종료하려면 버튼을 다시 누르세요.
Windows에서는 중지를 누르면 디버깅 대상과 해당 자식 프로세스가 강제로 종료됩니다.
소스 맵
VS Code의 JavaScript 디버거는 TypeScript 또는 축소/난독화된 JavaScript와 같은 변환된 언어를 디버깅하는 데 도움이 되는 소스 맵을 지원합니다. 소스 맵을 사용하면 원본 소스에서 한 단계씩 실행하거나 중단점을 설정할 수 있습니다. 원본 소스에 대한 소스 맵이 없거나 소스 맵이 손상되어 소스와 생성된 JavaScript 간의 매핑이 성공하지 못하면 중단점은 확인되지 않은(회색 빈 원)으로 표시됩니다.
기본값 true인 sourceMaps 속성은 소스 맵 기능을 제어합니다. 디버거는 항상 소스 맵을 사용하려고 시도합니다(찾을 수 있는 경우). 그 결과 program 속성을 사용하여 소스 파일(예: app.ts)을 지정할 수도 있습니다. 어떤 이유로 소스 맵을 비활성화해야 하는 경우 sourceMaps 속성을 false로 설정할 수 있습니다.
도구 구성
소스 맵이 항상 자동으로 생성되는 것은 아니므로, 변환기가 소스 맵을 생성하도록 구성해야 합니다. 예를 들어
TypeScript
TypeScript의 경우 tsc에 --sourceMap을 전달하거나 tsconfig.json 파일에 "sourceMap": true를 추가하여 소스 맵을 활성화할 수 있습니다.
tsc --sourceMap --outDir bin app.ts
Babel
Babel의 경우 sourceMaps 옵션을 true로 설정하거나 코드를 컴파일할 때 --source-maps 옵션을 전달해야 합니다.
npx babel script.js --out-file script-compiled.js --source-maps
Webpack
Webpack에는 다양한 소스 맵 옵션이 있습니다. 최상의 결과 충실도를 위해 webpack.config.js에서 devtool: "source-map" 속성을 설정하는 것이 좋습니다. 빌드 속도 저하를 유발하는 다른 설정을 실험해 볼 수도 있습니다.
또한 Webpack에 TypeScript 로더 사용과 같은 추가 컴파일 단계가 있는 경우 해당 단계가 소스 맵을 생성하도록 설정되었는지 확인해야 합니다. 그렇지 않으면 Webpack이 생성하는 소스 맵은 실제 소스가 아닌 로더에서 컴파일된 코드로 매핑됩니다.
소스 맵 검색
기본적으로 VS Code는 node_modules를 제외한 전체 작업 영역에서 소스 맵을 검색합니다. 대규모 작업 영역에서는 이 검색이 느릴 수 있습니다. launch.json의 outFiles 속성을 설정하여 VS Code가 소스 맵을 검색할 위치를 구성할 수 있습니다. 예를 들어 이 구성은 bin 폴더의 .js 파일에 대한 소스 맵만 검색합니다.
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch TypeScript",
"type": "node",
"request": "launch",
"program": "app.ts",
"outFiles": ["${workspaceFolder}/bin/**/*.js"]
}
]
}
outFiles는 소스 맵 파일(.js 대신 .map으로 끝날 수 있음)이 아닌 JavaScript 파일과 일치해야 합니다.
소스 맵 해석
기본적으로 outFiles의 소스 맵만 해석됩니다. 이 동작은 종속성이 중단점 설정에 영향을 미치는 것을 방지하는 데 사용됩니다. 예를 들어 src/index.ts 파일이 있고 종속성에 webpack:///./src/index.ts를 참조하는 소스 맵이 있는 경우, 이는 잘못하여 해당 소스 파일로 해석되어 예기치 않은 결과를 초래할 수 있습니다.
resolveSourceMapLocations 옵션을 설정하여 이 동작을 구성할 수 있습니다. null로 설정하면 모든 소스 맵이 해석됩니다. 예를 들어 이 구성은 node_modules/some-dependency의 소스 맵도 해석할 수 있도록 합니다.
"resolveSourceMapLocations": [
"out/**/*.js",
"node_modules/some-dependency/**/*.js",
]
스마트 단계
실행 구성에서 smartStep 속성을 true로 설정하면, VS Code는 디버거에서 코드를 단계별로 실행할 때 '불필요한 코드'를 자동으로 건너뜁니다. '불필요한 코드'는 변환 프로세스에 의해 생성되었지만 소스 맵으로 처리되지 않아 원본 소스로 매핑되지 않는 코드입니다. 이 코드는 디버거에서 원본 소스 코드와 관심 없는 생성 코드 간에 전환되기 때문에 소스 코드를 단계별로 실행할 때 방해가 됩니다. smartStep은 소스 맵으로 처리되는 위치에 다시 도달할 때까지 소스 맵으로 처리되지 않는 코드를 자동으로 단계별로 실행합니다.
스마트 단계는 특히 TypeScript의 async/await 다운컴파일과 같이 컴파일러가 소스 맵으로 처리되지 않는 도우미 코드를 삽입하는 경우 유용합니다.
smartStep 기능은 소스에서 생성되었으며 따라서 소스 맵이 있는 JavaScript 코드에만 적용됩니다. 소스가 없는 JavaScript의 경우 스마트 단계 옵션은 효과가 없습니다.
JavaScript 소스 맵 팁
소스 맵을 사용하여 디버깅할 때 일반적인 문제는 중단점을 설정하면 회색으로 변하는 것입니다. 커서를 위에 올려놓으면 "소스 맵 문제로 인해 중단점이 무시되었습니다"라는 메시지가 표시됩니다. 이제 어떻게 해야 할까요? 이 문제에는 여러 가지 원인이 있을 수 있습니다. 먼저 Node 디버그 어댑터가 소스 맵을 처리하는 방법에 대한 간단한 설명입니다.
app.ts에 중단점을 설정하면 디버그 어댑터는 실제로 Node에서 실행되는 TypeScript 파일의 변환된 버전인 app.js의 경로를 파악해야 합니다. 하지만 .ts 파일에서 시작하여 이를 파악하는 쉬운 방법은 없습니다. 대신 디버그 어댑터는 launch.json의 outFiles 속성을 사용하여 모든 변환된 .js 파일을 찾고 소스 맵을 파싱합니다. 이 소스 맵에는 해당 .ts 파일의 위치가 포함되어 있습니다.
소스 맵이 활성화된 상태로 app.ts 파일을 TypeScript로 빌드하면 app.js.map 파일이 생성되거나 app.js 파일 하단의 주석에 base64로 인코딩된 문자열로 소스 맵이 인라인으로 포함됩니다. 이 맵과 연결된 .ts 파일을 찾기 위해 디버그 어댑터는 소스 맵의 두 속성인 sources와 sourceRoot를 확인합니다. sourceRoot는 선택 사항입니다. 존재하면 sources(경로 배열)의 각 경로 앞에 붙습니다. 결과는 .ts 파일에 대한 절대 또는 상대 경로 배열이 됩니다. 상대 경로는 소스 맵을 기준으로 해석됩니다.
마지막으로 디버그 어댑터는 이 결과 .ts 파일 목록에서 app.ts의 전체 경로를 검색합니다. 일치하는 항목이 있으면 app.ts를 app.js에 매핑하는 데 사용할 소스 맵 파일을 찾은 것입니다. 일치하는 항목이 없으면 중단점을 바인딩할 수 없으며 회색으로 표시됩니다.
중단점이 회색으로 변할 때 시도해 볼 만한 몇 가지 방법이 있습니다.
- 디버깅 중 디버그: 중단점 문제 진단 명령을 실행하세요. 이 명령은 명령 팔레트(⇧⌘P (Windows, Linux Ctrl+Shift+P))에서 문제를 해결하는 데 도움이 되는 힌트를 제공하는 도구를 표시합니다.
- 소스 맵이 활성화된 상태로 빌드했습니까?
.js파일에.js.map파일 또는 인라인 소스 맵이 있는지 확인하세요. - 소스 맵의
sourceRoot및sources속성이 올바르게 지정되었습니까? 이들을 결합하여.ts파일의 올바른 경로를 얻을 수 있습니까? - 명령줄에서
code FOO와 같이foo/폴더를 열었을 때 VS Code에 잘못된 대소문자로 폴더를 열었습니까? 이 경우 소스 맵이 올바르게 해석되지 않을 수 있습니다. - Stack Overflow에서 특정 설정에 대한 도움말을 검색하거나 GitHub에 이슈를 제출해 보세요.
debugger문을 추가해 보세요..ts파일에서 중단되면 해당 지점의 중단점이 바인딩되지 않는 경우 GitHub 이슈와 함께 포함할 유용한 정보가 됩니다.
소스 맵 경로 재정의
디버거는 sourceMapPathOverrides를 사용하여 사용자 지정 소스 맵-디스크 경로 매핑을 구현합니다. 대부분의 도구에는 좋은 기본값이 설정되어 있지만, 고급 사용 사례에서는 사용자 지정해야 할 수 있습니다. 기본 경로 재정의는 다음과 같은 객체 맵입니다.
{
'webpack:///./~/*': "${workspaceFolder}/node_modules/*",
'webpack:////*': '/*',
'webpack://@?:*/?:*/*': "${workspaceFolder}/*",
// and some more patterns...
}
이것은 소스 맵의 경로 또는 URL을 왼쪽에서 오른쪽으로 매핑합니다. 패턴 ?:*는 비탐욕적, 비캡처 일치이고 *는 탐욕적 캡처 일치입니다. 그런 다음 디버거는 오른쪽 패턴의 해당 *를 소스 맵 경로에서 캡처된 조각으로 바꿉니다. 예를 들어, 위의 예에서 마지막 패턴은 webpack://@my/package/foo/bar를 ${workspaceFolder}/foo/bar에 매핑합니다.
참고로 브라우저 디버깅의 경우, webRoot는 기본 sourceMapPathOverrides에서 workspaceFolder 대신 사용됩니다.
원격 디버깅
참고: VS Code에는 보편적인 원격 개발 기능이 있습니다. 원격 개발 확장을 사용하면 원격 시나리오 및 컨테이너의 Node.js 개발은 로컬 설정의 Node.js 개발과 다르지 않습니다. 이것이 Node.js 프로그램을 원격 디버깅하는 권장 방법입니다. 시작하기 섹션과 원격 튜토리얼을 확인하여 자세히 알아보세요.
원격 개발 확장을 사용하여 Node.js 프로그램을 디버깅할 수 없는 경우, 로컬 VS Code 인스턴스에서 원격 Node.js 프로그램을 디버깅하는 방법에 대한 가이드입니다.
Node.js 디버거는 다른 머신 또는 컨테이너에서 실행 중인 프로세스에 연결하는 원격 디버깅을 지원합니다. address 속성을 통해 원격 호스트를 지정합니다. 예를 들어
{
"type": "node",
"request": "attach",
"name": "Attach to remote",
"address": "192.168.148.2", // <- remote address here
"port": 9229
}
기본적으로 VS Code는 디버깅 중인 소스를 원격 Node.js 폴더에서 로컬 VS Code로 스트리밍하고 읽기 전용 편집기에 표시합니다. 이 코드를 단계별로 실행할 수 있지만 수정할 수는 없습니다. 대신 작업 공간에서 편집 가능한 소스를 열도록 하려면 원격 위치와 로컬 위치 간에 매핑을 설정할 수 있습니다. localRoot 및 remoteRoot 속성을 사용하여 로컬 VS Code 프로젝트와 (원격) Node.js 폴더 간의 경로를 매핑할 수 있습니다. 이는 로컬 시스템에서 로컬로 또는 서로 다른 운영 체제 간에도 작동합니다. 원격 Node.js 폴더에서 로컬 VS Code 경로로 코드 경로를 변환해야 할 때마다 remoteRoot 경로가 경로에서 제거되고 localRoot로 대체됩니다. 반대 변환의 경우 localRoot 경로가 remoteRoot로 대체됩니다.
{
"type": "node",
"request": "attach",
"name": "Attach to remote",
"address": "TCP/IP address of process to be debugged",
"port": 9229,
"localRoot": "${workspaceFolder}",
"remoteRoot": "C:\\Users\\username\\project\\server"
}
로드된 스크립트 액세스
작업 공간의 일부가 아니어서 일반 VS Code 파일 탐색으로 쉽게 찾고 열 수 없는 스크립트에 중단점을 설정해야 하는 경우, 실행 및 디버그 보기의 로드된 스크립트 보기를 통해 로드된 스크립트에 액세스할 수 있습니다.
로드된 스크립트 보기를 사용하면 스크립트 이름을 입력하여 빠르게 선택하거나 입력 시 필터 사용이 켜져 있을 때 목록을 필터링할 수 있습니다.
스크립트는 읽기 전용 편집기에 로드되며, 여기에서 중단점을 설정할 수 있습니다. 이러한 중단점은 디버깅 세션 간에 유지되지만, 디버깅 세션이 실행 중일 때만 스크립트 콘텐츠에 액세스할 수 있습니다.
소스 코드를 편집할 때 디버그 세션을 자동으로 다시 시작
시작 구성의 restart 속성은 디버깅 세션이 종료된 후 Node.js 디버거가 자동으로 다시 시작되는지 여부를 제어합니다. 이 기능은 파일 변경 시 Node.js를 다시 시작하기 위해 nodemon을 사용하는 경우 유용합니다. 시작 구성 속성 restart를 true로 설정하면 Node.js가 종료된 후 노드 디버거가 자동으로 Node.js에 다시 연결하려고 시도합니다.
명령줄에서 server.js 프로그램을 nodemon을 통해 다음과 같이 시작한 경우
nodemon --inspect server.js
다음과 같은 시작 구성으로 VS Code 디버거를 연결할 수 있습니다.
{
"name": "Attach to node",
"type": "node",
"request": "attach",
"restart": true,
"port": 9229
}
대안으로, 시작 구성으로 server.js 프로그램을 nodemon을 통해 직접 시작하고 VS Code 디버거를 연결할 수 있습니다.
{
"name": "Launch server.js via nodemon",
"type": "node",
"request": "launch",
"runtimeExecutable": "nodemon",
"program": "${workspaceFolder}/server.js",
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen"
}
팁: 중지 버튼을 누르면 디버깅 세션이 중지되고 Node.js 연결이 해제되지만, nodemon(및 Node.js)은 계속 실행됩니다. nodemon을 중지하려면 명령줄에서 종료해야 합니다(위에서 표시된
integratedTerminal을 사용하는 경우 쉽게 가능합니다).
팁: 구문 오류가 있는 경우, 오류가 수정될 때까지 nodemon은 Node.js를 성공적으로 시작할 수 없습니다. 이 경우 VS Code는 Node.js에 계속 연결을 시도하지만 결국 포기합니다(10초 후). 이를 방지하기 위해 밀리초 단위의 더 큰 값으로
timeout속성을 추가하여 시간 초과를 늘릴 수 있습니다.
프레임 다시 시작
노드 디버거는 스택 프레임에서 실행을 다시 시작하는 것을 지원합니다. 이는 소스 코드에서 문제를 발견하고 수정된 입력 값으로 코드의 작은 부분을 다시 실행하려는 상황에서 유용할 수 있습니다. 전체 디버깅 세션을 중지했다가 다시 시작하는 것은 시간이 많이 걸릴 수 있습니다. 프레임 다시 시작 작업을 사용하면 값 설정 작업을 사용하여 변수를 변경한 후 현재 함수를 다시 입력할 수 있습니다.
프레임 다시 시작은 함수 외부의 상태에 대한 변경 사항을 롤백하지 않으므로 항상 예상대로 작동하지 않을 수 있습니다.
중단점
조건부 중단점
조건부 중단점은 식이 참 값을 반환할 때만 일시 중지되는 중단점입니다. 줄 번호 옆의 여백을 마우스 오른쪽 버튼으로 클릭하고 "조건부 중단점"을 선택하여 만들 수 있습니다.
로그 포인트
어떤 경우에는 코드가 특정 위치에 도달했을 때 일시 중지하는 대신 메시지나 값을 기록하고 싶을 수 있습니다. 로그포인트를 사용하여 이를 수행할 수 있습니다. 로그포인트는 일시 중지되지 않고, 대신 히트될 때 디버그 콘솔에 메시지를 기록합니다. JavaScript 디버거에서는 중괄호를 사용하여 메시지에 식을 삽입할 수 있습니다. 예: current value is: {myVariable.property}.
줄 번호 옆의 여백을 마우스 오른쪽 버튼으로 클릭하고 "로그포인트"를 선택하여 만들 수 있습니다. 예를 들어, 이것은 location is /usr/local과 같이 기록될 수 있습니다.
히트 횟수 중단점
'히트 횟수 조건'은 중단점이 '중단' 실행되기 전에 몇 번 히트되어야 하는지를 제어합니다. 줄 번호 옆의 여백을 마우스 오른쪽 버튼으로 클릭하고 "조건부 중단점"을 선택한 다음 "히트 횟수"로 전환하여 히트 횟수 중단점을 배치할 수 있습니다.
Node.js 디버거에서 지원하는 히트 횟수 구문은 정수이거나 연산자 <, <=, ==, >, >=, % 중 하나와 정수입니다.
일부 예제
>1010번 히트 후 항상 중단<3처음 두 번의 히트에서만 중단10>=10과 동일%2두 번마다 한 번씩 히트할 때 중단
트리거된 중단점
트리거된 중단점은 다른 중단점이 히트되면 자동으로 활성화되는 중단점입니다. 특정 사전 조건 후에만 발생하는 코드의 실패 사례를 진단할 때 매우 유용할 수 있습니다.
트리거된 중단점은 글리프 여백을 마우스 오른쪽 버튼으로 클릭하고 트리거된 중단점 추가를 선택한 다음 어떤 다른 중단점이 중단점을 활성화하는지 선택하여 설정할 수 있습니다.
중단점 유효성 검사
성능상의 이유로 Node.js는 JavaScript 파일 내의 함수를 첫 번째 액세스 시 지연적으로 구문 분석합니다. 결과적으로 Node.js에서 아직 보지 못한(구문 분석되지 않은) 소스 코드 영역에서는 중단점이 작동하지 않습니다.
이 동작은 디버깅에 이상적이지 않으므로 VS Code는 자동으로 --nolazy 옵션을 Node.js에 전달합니다. 이렇게 하면 지연된 구문 분석이 방지되고 코드를 실행하기 전에 중단점을 유효성 검사할 수 있습니다(따라서 더 이상 "점프"하지 않음).
--nolazy 옵션은 디버그 대상의 시작 시간을 상당히 증가시킬 수 있으므로, runtimeArgs 속성으로 --lazy를 전달하여 쉽게 옵트아웃할 수 있습니다.
그렇게 하면 일부 중단점이 요청한 줄에 "고정"되지 않고 이미 구문 분석된 코드의 다음 가능한 줄로 "점프"하는 것을 볼 수 있습니다. 혼동을 피하기 위해 VS Code는 항상 Node.js가 중단점이 있다고 생각하는 위치에 중단점을 표시합니다. 중단점 섹션에서 이러한 중단점은 요청된 줄 번호와 실제 줄 번호 사이에 화살표가 표시됩니다.
이 중단점 유효성 검사는 세션이 시작되고 중단점이 Node.js에 등록될 때 또는 세션이 이미 실행 중이고 새 중단점이 설정될 때 발생합니다. 이 경우 중단점이 다른 위치로 "점프"할 수 있습니다. Node.js가 모든 코드를 구문 분석한 후(예: 코드를 실행하여) 중단점 섹션 헤더의 다시 적용 버튼을 사용하여 중단점을 요청된 위치에 쉽게 다시 적용할 수 있습니다. 이렇게 하면 중단점이 요청된 위치로 "점프"해야 합니다.
불필요한 코드 건너뛰기
VS Code Node.js 디버깅에는 건너뛰고 싶지 않은 소스 코드( '내 코드만'이라고도 함)를 피하는 기능이 있습니다. 이 기능은 시작 구성의 skipFiles 속성을 사용하여 활성화할 수 있습니다. skipFiles는 건너뛸 스크립트 경로에 대한 glob 패턴의 배열입니다.
예를 들어
"skipFiles": [
"${workspaceFolder}/node_modules/**/*.js",
"${workspaceFolder}/lib/**/*.js"
]
node_modules 및 lib 폴더의 모든 코드가 건너뛰게 됩니다. skipFiles는 console.log와 같은 메서드를 호출할 때 표시되는 위치에도 적용됩니다. 스택에서 첫 번째 건너뛰지 않은 위치가 디버그 콘솔의 출력 옆에 표시됩니다.
Node.js의 내장 **핵심 모듈**은 glob 패턴에서 <node_internals>라는 '마법 이름'으로 참조할 수 있습니다. 다음 예는 모든 내부 모듈을 건너뜁니다.
"skipFiles": [
"<node_internals>/**/*.js"
]
정확한 '건너뛰기' 규칙은 다음과 같습니다.
- 건너뛴 파일로 들어가면 거기서 멈추지 않습니다. 건너뛴 파일에 없는 다음 실행 줄에서 멈춥니다.
- 예외가 발생할 때 중단하도록 옵션을 설정했다면, 건너뛴 파일에서 발생한 예외가 건너뛰지 않은 파일로 버블 업되지 않는 한 해당 예외에서는 중단되지 않습니다.
- 건너뛴 파일에 중단점을 설정하면 해당 중단점에서 멈추고, 함수 밖으로 나갈 때까지 단계별 실행할 수 있으며, 그 후에는 일반 건너뛰기 동작이 재개됩니다.
- 건너뛴 파일에서 발생하는 콘솔 메시지의 위치는 호출 스택에서 건너뛰지 않은 첫 번째 위치로 표시됩니다.
건너뛴 소스는 호출 스택 보기에서 '흐릿한' 스타일로 표시됩니다.
흐릿한 항목에 마우스를 올리면 호출 스택 프레임이 흐릿한 이유를 설명합니다.
호출 스택의 상황에 맞는 메뉴 항목인 이 파일 건너뛰기 토글을 사용하면 시작 구성에 추가하지 않고도 런타임에 파일을 쉽게 건너뛸 수 있습니다. 이 옵션은 현재 디버깅 세션 동안에만 지속됩니다. 또한 시작 구성의 skipFiles 옵션으로 건너뛰는 파일을 건너뛰지 않도록 설정하는 데 사용할 수도 있습니다.
참고:
legacy프로토콜 디버거는 음수 glob 패턴을 지원하지만, 반드시 양수 패턴 **뒤에** 와야 합니다. 양수 패턴은 건너뛴 파일 집합에 추가하고, 음수 패턴은 해당 집합에서 제거합니다.
다음 (legacy 프로토콜 전용) 예에서는 'math' 모듈을 제외한 모든 것이 건너뜁니다.
"skipFiles": [
"${workspaceFolder}/node_modules/**/*.js",
"!${workspaceFolder}/node_modules/math/**/*.js"
]
참고:
legacy프로토콜 디버거는 V8 디버거 프로토콜이 기본적으로 지원하지 않기 때문에skipFiles기능을 에뮬레이션해야 합니다. 이로 인해 단계별 실행 성능이 저하될 수 있습니다.
WebAssembly 디버깅
JavaScript 디버거는 DWARF 디버그 정보를 포함하는 경우 WebAssembly로 컴파일된 코드를 디버깅할 수 있습니다. 많은 툴체인에서 이 정보를 내보내는 것을 지원합니다.
- Emscripten을 사용한 C/C++: 디버그 정보를 내보내려면
-g플래그로 컴파일합니다. - Zig: DWARF 정보는 "Debug" 빌드 모드에서 자동으로 내보내집니다.
- Rust: Rust는 DWARF 디버그 정보를 내보냅니다. 그러나 wasm-pack은 빌드 중에 아직 이를 유지하지 않습니다. 따라서
wasm-pack build를 실행하는 대신, 일반적인 wasm-bindgen/wasm-pack 라이브러리 사용자는 두 명령을 사용하여 수동으로 빌드해야 합니다.cargo install wasm-bindgen-cli를 한 번 실행하여 필요한 명령줄 도구를 설치합니다.cargo build --target wasm32-unknown-unknown을 실행하여 라이브러리를 빌드합니다.wasm-bindgen --keep-debug --out-dir pkg ./target/wasm32-unknown-unknown/debug/<library-name>.wasm <extra-arguments>를 실행하여 WebAssembly 바인딩을 생성하고,<library-name>을 Cargo.toml의 이름으로 바꾸고<extra-arguments>를 필요에 따라 구성합니다.
코드가 빌드되면 WebAssembly DWARF Debugging 확장을 설치하고 싶을 것입니다. 이 확장은 VS Code 코어를 '간소화'하기 위해 별도의 확장으로 제공됩니다. 설치 후 활성 디버깅 세션을 다시 시작하면 네이티브 코드가 디버거에서 매핑되어야 합니다! 로드된 소스 보기에서 소스 코드가 표시되고 중단점이 작동해야 합니다.
아래 이미지에서 디버거는 Mandelbrot 프랙탈을 생성하는 C++ 소스 코드의 중단점에서 중지됩니다. 호출 스택이 표시되며, JavaScript 코드, WebAssembly, 매핑된 C++ 코드로 프레임이 이동합니다. C++ 코드의 변수와 int32 height 변수와 관련된 메모리 편집도 볼 수 있습니다.
거의 일치하지만, WebAssembly 디버깅은 일반 JavaScript와 약간 다릅니다.
- 변수 보기의 변수는 직접 편집할 수 없습니다. 그러나 변수 옆의 이진 데이터 보기 작업을 선택하여 연결된 메모리를 편집할 수 있습니다.
- 디버그 콘솔 및 조사식 보기의 기본 식 평가는 lldb-eval에 의해 제공됩니다. 이는 일반 JavaScript 식과 다릅니다.
- 소스 코드로 매핑되지 않은 위치는 분해된 WebAssembly 텍스트 형식으로 표시됩니다. WebAssembly의 경우 소스 맵 단계 건너뛰기 명령을 사용하면 디버거가 분해된 코드에서만 단계별 실행됩니다.
VS Code의 WebAssembly 디버깅은 Chromium 작성자의 C/C++ Debugging Extension을 기반으로 구축됩니다.
지원되는 Node와 유사한 런타임
현재 VS Code JavaScript 디버거는 Node 버전 8.x 이상, 최신 Chrome 버전, 최신 Edge 버전(msedge 시작 유형 사용)을 지원합니다.
다음 단계
Node.js 섹션을 아직 읽지 않았다면 다음을 확인하세요.
- Node.js - 샘플 애플리케이션과 함께하는 엔드 투 엔드 Node 시나리오
VS Code 디버깅의 기본 사항에 대한 튜토리얼을 보려면 이 동영상을 확인하세요.
VS Code의 작업 실행 지원에 대해 알아보려면 다음으로 이동하세요.
- 작업 - Gulp, Grunt, Jake로 작업 실행. 오류 및 경고 표시
자신만의 디버거 확장을 작성하려면 다음을 방문하세요.
- 디버거 확장 - 모의 샘플부터 시작하는 VS Code 디버그 확장 생성 단계
자주 묻는 질문
심볼릭 링크를 사용할 때 디버깅할 수 있나요?
예, 프로젝트 내의 폴더에 대해 npm link와 같이 심볼릭 링크를 만든 경우, Node.js 런타임에 심볼릭 링크 경로를 유지하도록 지시하여 심볼릭 링크된 소스를 디버깅할 수 있습니다. 시작 구성 runtimeArgs 속성에서 Node.exe의 --preserve-symlinks 스위치를 사용합니다. 문자열 배열인 runtimeArgs는 기본적으로 node.exe인 디버깅 세션 런타임 실행 파일에 전달됩니다.
{
"runtimeArgs": ["--preserve-symlinks"]
}
주요 스크립트가 심볼릭 링크된 경로에 있는 경우 "--preserve-symlinks-main" 옵션도 추가해야 합니다. 이 옵션은 Node 10 이상에서만 사용할 수 있습니다.
ECMAScript 모듈은 어떻게 디버깅하나요?
esM을 사용하거나 ECMAScript 모듈을 사용하기 위해 Node.js에 --experimental-modules를 전달하는 경우, launch.json의 runtimeArgs 속성을 통해 이러한 옵션을 전달할 수 있습니다.
"runtimeArgs": ["--experimental-modules"]- Node v8.5.0 이상에서 실험적인 ECMAScript 모듈 지원 사용"runtimeArgs": ["-r", "esm"]- esm ES 모듈 로더 사용 (쉼표 없이["-r esm"]은 작동하지 않음)
NODE_OPTIONS는 어떻게 설정하나요?
디버거는 특별한 NODE_OPTIONS 환경 변수를 사용하여 애플리케이션 디버깅을 설정하며, 이를 덮어쓰면 디버깅이 제대로 작동하지 않습니다. 덮어쓰는 대신 추가해야 합니다. 예를 들어 .bashrc 파일에 다음과 같은 내용이 있을 수 있습니다.
export NODE_OPTIONS="$NODE_OPTIONS --some-other-option=here"