소개
오늘날 작성자는 다양한 추상화를 사용하여 웹 애플리케이션을 빌드할 수 있습니다. 많은 작성자들은 웹 플랫폼이 제공하는 하위 레벨의 API와 직접 인터페이스하는 대신 프레임워크, 빌드 도구 및 컴파일러를 활용하여 더 높은 수준의 관점에서 애플리케이션을 작성합니다.
예를 들어, Angular 프레임워크를 기반으로 빌드된 구성요소는 HTML 템플릿을 사용하여 TypeScript로 작성됩니다. 내부적으로 Angular CLI와 webpack은 모든 것을 자바스크립트로 컴파일하고 이른바 번들로 컴파일한 후 브라우저로 전송합니다.
DevTools에서 웹 애플리케이션을 디버깅하거나 프로파일링할 때 현재는 실제로 작성한 코드 대신 컴파일된 버전의 코드를 보고 디버그할 수 있습니다. 하지만 저자 입장에서는 바람직하지 않습니다.
- 축소된 JavaScript 코드를 디버그하는 것이 아니라 원본 JavaScript 코드를 디버그하는 것이 좋습니다.
- TypeScript를 사용할 때는 JavaScript를 디버그하는 것이 아니라 원래 TypeScript 코드를 디버그해야 합니다.
- Angular, Lit 또는 JSX와 같은 템플릿을 사용할 때 결과 DOM을 디버그할 필요가 없는 경우도 있습니다. 구성요소 자체를 디버그하는 것이 좋습니다.
전반적으로 작성한 대로 자체 코드를 디버그하는 것이 좋습니다.
소스 맵이 이미 이 간극을 어느 정도 해소했지만, Chrome DevTools 및 생태계가 이 영역에서 할 수 있는 일들은 더 많습니다.
그럼 확인해 볼까요?
작성된 코드와 배포된 코드 비교
현재 Sources 패널에서 파일 트리를 탐색하면 컴파일된 번들의 콘텐츠를 볼 수 있습니다. 이러한 파일은 브라우저에서 다운로드하고 실행하는 실제 파일입니다. DevTools에서는 이를 배포된 코드라고 합니다.
이것은 그다지 편리하지 않으며 이해하기 어려운 경우가 많습니다. 작성자는 배포된 코드가 아니라 작성한 코드를 확인하고 디버그해야 합니다.
이를 보완하기 위해 이제 트리에 작성된 코드가 대신 표시되도록 할 수 있습니다. 이렇게 하면 트리가 IDE에서 볼 수 있는 소스 파일과 더 유사해지며 이제 이러한 파일이 배포된 코드에서 분리됩니다.
Chrome DevTools에서 이 옵션을 사용 설정하려면 설정 > 실험을 클릭하고 소스를 작성 및 배포 트리로 그룹화를 선택합니다.
'코드만'
종속 항목을 사용하거나 프레임워크를 기반으로 빌드하는 경우 서드 파티 파일이 방해가 될 수 있습니다. 대부분의 경우 node_modules 폴더에 숨겨진 일부 서드 파티 라이브러리의 코드가 아닌 코드만 표시하려고 합니다.
이를 보완하기 위해 DevTools에는 기본적으로 알려진 서드 파티 스크립트를 무시 목록에 추가라는 추가 설정이 기본적으로 사용 설정되어 있습니다. 이 도구는 DevTools > 설정 > 무시 목록.
이 설정을 사용하면 DevTools가 프레임워크 또는 빌드 도구에서 무시로 표시한 파일이나 폴더를 숨깁니다.
Angular v14.1.0부터 node_modules 및 webpack 폴더의 콘텐츠가 그렇게 표시됩니다. 따라서 이러한 폴더, 폴더 안에 있는 파일, 기타 서드 파티 아티팩트는 DevTools의 여러 위치에 표시되지 않습니다.
이 새로운 동작을 사용 설정하기 위해 작성자는 아무것도 할 필요가 없습니다. 이 변경사항을 구현하는 것은 프레임워크에 달려 있습니다.
스택 트레이스에서 무시 나열된 코드
무시 목록에 포함된 이러한 파일이 더 이상 표시되지 않는 위치는 스택 트레이스입니다. 개발자는 이제 더 많은 관련 스택 트레이스를 볼 수 있습니다.
스택 트레이스의 모든 호출 프레임을 보려면 언제든지 프레임 더 보기 링크를 클릭하면 됩니다.
코드를 디버깅하고 단계별로 실행하는 동안 표시되는 호출 스택에도 동일하게 적용됩니다. 프레임워크나 번들러가 DevTools에 서드 파티 스크립트에 관해 알리면 DevTools는 단계 디버깅 중에 관련 없는 모든 호출 프레임을 자동으로 숨기고 무시 목록에 있는 코드 위로 이동합니다.
파일 트리에서 무시 나열된 코드
소스 패널의 작성된 코드 파일 트리에서 무시 목록에 포함된 파일 및 폴더를 숨기려면 설정 > 실험을 참조하세요.
이제 샘플 Angular 프로젝트에서 node_modules 및 webpack 폴더가 숨겨집니다.
'빠른 열기' 메뉴에서 무시된 코드
무시된 코드는 파일 트리뿐만 아니라 '빠른 열기' 메뉴 (Control+P (Linux/Windows) 또는 Command+P (Mac))에서도 숨겨집니다.
스택 트레이스 개선사항
관련 스택 트레이스를 이미 다뤘지만 Chrome DevTools는 스택 트레이스에 더 많은 개선사항을 도입합니다.
연결된 스택 트레이스
일부 작업이 비동기식으로 발생하도록 예약된 경우 DevTools의 스택 트레이스는 현재 이야기의 일부만 알려줍니다.
예를 들어 다음은 가상의 framework.js 파일에 있는 매우 간단한 스케줄러입니다.
function makeScheduler() {
const tasks = [];
return {
schedule(f) {
tasks.push({ f });
},
work() {
while (tasks.length) {
const { f } = tasks.shift();
f();
}
},
};
}
const scheduler = makeScheduler();
function loop() {
scheduler.work();
requestAnimationFrame(loop);
};
loop();
개발자가 example.js 파일의 자체 코드에서 이를 사용할 수 있는 방법은 다음과 같습니다.
function someTask() {
console.trace("done!");
}
function businessLogic() {
scheduler.schedule(someTask);
}
businessLogic();
someTask 메서드 내에 중단점을 추가하거나 콘솔에 출력된 트레이스를 검사할 때 이 작업의 '근본 원인'인 businessLogic() 호출이 언급된 것을 볼 수 없습니다.
대신 작업 실행을 유도한 프레임워크 예약 로직만 표시되고 스택 트레이스에는 탐색경로가 없어 이 작업으로 이어지는 이벤트 간의 인과관계를 파악하는 데 도움이 됩니다.
'Async Stack Tagging'이라는 새로운 기능 덕분에 비동기 코드의 두 부분을 함께 연결하여 전체적인 상황을 파악할 수 있습니다.
Async Stack Tagging API에는 console.createTask()라는 새로운 console 메서드가 도입되었습니다. API 서명은 다음과 같습니다.
interface Console {
createTask(name: string): Task;
}
interface Task {
run<T>(f: () => T): T;
}
console.createTask() 호출은 나중에 작업의 콘텐츠 f를 실행하는 데 사용할 수 있는 Task 인스턴스를 반환합니다.
// Task Creation
const task = console.createTask(name);
// Task Execution
task.run(f);
작업은 작업이 생성된 컨텍스트와 실행 중인 비동기 함수의 컨텍스트를 연결합니다.
위의 makeScheduler 함수에 적용하면 코드가 다음과 같이 됩니다.
function makeScheduler() {
const tasks = [];
return {
schedule(f) {
const task = console.createTask(f.name);
tasks.push({ task, f });
},
work() {
while (tasks.length) {
const { task, f } = tasks.shift();
task.run(f); // instead of f();
}
},
};
}
덕분에 Chrome DevTools는 이제 더 나은 스택 트레이스를 표시할 수 있습니다.
이제 businessLogic()가 스택 트레이스에 어떻게 포함되었는지 확인합니다. 뿐만 아니라 작업은 이전처럼 일반적인 requestAnimationFrame 대신 someTask 친숙한 이름을 사용합니다.
친근한 통화 프레임
프로젝트를 빌드할 때 프레임워크는 HTML 형식의 코드를 결국 브라우저에서 실행되는 일반 JavaScript로 변환하는 Angular 또는 JSX 템플릿과 같이 프로젝트를 빌드할 때 모든 종류의 템플릿 언어로 코드를 생성하는 경우가 많습니다. 이렇게 생성된 함수 유형에 친숙하지 않은 이름이 지정되기도 합니다. 축소된 후의 단일 문자 이름이나 별다른 구분 없이 모호하거나 생소한 이름이 사용되기도 합니다.
샘플 프로젝트에서 이에 관한 예는 스택 트레이스에서 볼 수 있는 AppComponent_Template_app_button_handleClick_1_listener입니다.
이 문제를 해결하기 위해 이제 Chrome DevTools는 소스 맵을 통해 이러한 함수의 이름을 바꿀 수 있습니다. 소스 맵에 함수 범위의 시작 부분에 대한 이름 항목이 있는 경우 호출 프레임은 스택 트레이스에 그 이름을 표시해야 합니다.
이 새로운 동작을 사용 설정하기 위해 작성자는 아무것도 할 필요가 없습니다. 이 변경사항을 구현하는 것은 프레임워크에 달려 있습니다.
향후 계획
이 게시물에서 설명한 추가 사항 덕분에, Chrome DevTools는 더 나은 디버깅 환경을 제공할 수 있습니다. 팀이 탐구하고 싶은 영역이 더 있습니다. 특히 DevTools에서 프로파일링 환경을 개선하는 방법을 다룹니다.
Chrome DevTools 팀은 프레임워크 작성자가 이러한 새로운 기능을 채택하도록 권장합니다. 우수사례: DevTools로 Angular 디버깅 개선에서 구현 방법을 확인할 수 있습니다.