오늘의 주인공은 SourceMapDevToolPlugin 플러그인입니다. 왜 사용하고 뭐가 좋은지 알아보도록 하겠습니다.
기존의 문제점
개발환경에서는 아무 문제가 없었지만 운영환경에서 오류가 났을 때 디버깅 하는 것이 여간 어려운 것이 아니다. 이유는 번들링 되어 있기 때문에 어떤 js파일을 가르키지만 그 js 파일은 내가 만든 모든 js 파일들이 모두 합쳐져 있기 때문에 찾을 수가 없다.
디버깅의 어려움
개발환경일 때는 다 따로 있으니 date.js에서 오류가 난 것을 쉽게 찾을 수 있다. 하지만 운영 환경일 경우 모두다 짬뽕이 되어 있기 때문에 bundle.js에서 오류가 난다고 해도 1도 도움이 안된다. 이런 부분을 해소해줄 수 있는 것이 바로 source map 이다.
사용방법
아래와 같이 설정하면 끝!
// webpack.config.js
{...
plugins: [
...
new webpack.SourceMapDevToolPlugin({
filename: "[file].map", // 소스 맵 파일명 설정
exclude: ["vendor.js"], // 특정 파일 제외 설정 (예시)
// 추가적인 옵션 설정 가능
}),
],
}
확인방법
mode를 production으로 설정
먼저 webpack의 모드를 production으로 변경하자. 그리고 플러그인 사용하고 안하고 차이를 개발창에서 보자
기본설정
아무것도 안보인다. 이래서 오류 찾기가 어렵다...
SourceMapDevToolPlugin 플러그인 추가
아무것도 안보인다. 내가 만든 파일이 주르륵 보인다. 오류났을 떄 어떤 파일에서 오류가 났는지 디버깅 하기 훨신 편할 것 같다.
문제점
장점도 있지만 문제점도 있다. 너무 잘 보이는게 문제인다... 이부분은 적당히 운영환경에서 보안상의 이유로 적당히 잘 가려야 한다. gpt는 아래와 방법이 있다고 한다.
인증된 사용자만 소스 맵에 접근 허용: 서버 설정을 통해 소스 맵 파일에 대한 접근을 인증된 사용자만 할 수 있도록 제한할 수 있습니다. 이를 위해 HTTP 기본 인증, OAuth, 또는 특정 IP 주소에서만 접근 가능하도록 설정할 수 있습니다.
Private Source Map:
소스 맵 파일을 공개적으로 접근 가능한 서버에 업로드하지 않고, 개발자의 로컬 머신이나 보안된 내부 네트워크에만 보관합니다. 이렇게 하면 외부에서는 소스 맵에 접근할 수 없으며, 오류 추적 서비스에서만 사용할 수 있습니다.
오류 추적 서비스 사용
Sentry, Rollbar, Bugsnag 등과 같은 오류 추적 서비스를 사용하면, 소스 맵을 이 서비스에 업로드하여 오류를 추적할 때만 사용할 수 있습니다. 이러한 서비스들은 일반적으로 인증을 요구하므로, 공개 인터넷에서는 소스 맵에 접근할 수 없습니다.
###환경 변수 사용
프로덕션 빌드 시에는 소스 맵을 생성하지 않도록 환경 변수를 사용할 수 있습니다. 개발 환경에서는 소스 맵을 생성하고, 실제 프로덕션 환경에서는 생성되지 않도록 환경별 설정을 다르게 할 수 있습니다.
소스 맵 파일 제거
프로덕션 빌드 후 배포 전에 소스 맵 파일을 삭제하는 빌드 스크립트를 사용할 수 있습니다. 이렇게 하면 파일이 서버에 존재하지 않게 되어 외부에서는 접근할 수 없습니다.
소스 맵 URL 수정
소스 맵 URL을 코드에서 제거하거나 변경하여 브라우저가 소스 맵을 로드하지 못하도록 합니다. 필요할 때만 URL을 원래대로 복원하거나 제공하여 디버깅할 수 있습니다.
상황에 따라 적절하게 설정하는 것이 중요할 것 같다..
