왜 인라인 소스 맵입니까?
오늘 저는 소스 맵을 별도의 example.min.map 파일에 넣는 대신 축소 된 JavaScript 파일에 직접 포함 할 수 있다는 것을 배웠습니다 . 나는 궁금하다 : 왜 누군가가 그렇게하고 싶어 할까요?
소스 맵을 사용 하는 이점은 분명 합니다. 예를 들어 축소 된 파일을 실행하는 동안 압축되지 않은 원본 소스 파일의 오류를 디버깅 할 수 있습니다. 최소화 의 이점도 분명합니다 . 소스 파일의 크기가 크게 줄어들어 브라우저가 더 빨리 다운로드 할 수 있습니다.
그렇다면 지도가 축소 된 코드 자체보다 크기가 더 크다는 점을 감안할 때 왜 지구상에서 축소 된 파일에 소스 맵을 포함하고 싶을 까요?
나는 주위를 검색했고 사람들이 소스 맵을 인라인으로 만드는 것을 볼 수 있었던 유일한 이유는 개발에 사용하기위한 것입니다. 인라인 소스 맵은 프로덕션에서 사용해서는 안됩니다.
축소 된 파일로 소스 맵을 인라인하는 합리적 이유는 브라우저가 개발 및 프로덕션에서 정확히 동일한 JavaScript를 구문 분석한다는 것입니다. Closure Compiler 와 같은 일부 축소 기는 '단지'코드 축소 이상의 역할을합니다. 고급 옵션을 사용하면 데드 코드 제거, 함수 인라인 또는 적극적인 변수 이름 변경과 같은 작업도 수행 할 수 있습니다. 이것은 축소 된 코드를 (잠재적으로) 소스 파일과 기능적으로 다르게 만듭니다.
물론 외부 소스 맵 파일을 참조하여이 작업을 수행 할 수 있지만 일부 사람들은 빌드 프로세스에 인라인을 선호하는 것 같습니다.
Android 기기에서 Chrome을 원격 디버깅하는 경우 Chrome 디버거는 기기에서 원하는 파일에 액세스 할 수 없으며 별도의지도 파일을 포함합니다. 인라인으로 포함하면이 문제가 발생하지 않습니다.
JS는 같은 도구를 번들 Browserify또는 Webpack모든 번들 것 .js조차 모드를 개발, 파일 입력 하나 또는 여러 번들. 따라서이 경우 생성 된 번들에 인라인 소스 맵을 추가하는 것이 추가 파일을 가져 오지 않고 디버깅을 돕는 가장 쉬운 방법입니다.
어떤 상황에서는 평가 된 코드에 인라인 소스 맵을 포함 할 수 있습니다. 예를 들어 coffeescript 입력 필드가 있고 coffeescript에서 코드를 디버깅 할 수 있습니다. 평가 된 코드의 소스 맵에 대한 스택 오버플로 질문이 있습니다.
댓글에 @sourceURL을 포함하여 평가 코드의 URL을 지정하고 맵 파일을로드 할 수 있습니다 ( SourceMap Spec 3의 8 페이지 참조 ). 그러나 항상 특정 위치에 파일을 쓸 수있는 것은 아닙니다.
cheap-module-source-map 프로덕션 빌드에 훨씬 좋습니다.
inline-source-map 테스트 할 때 빠르고 더러운 빌드를 만드는 데 사용됩니다.
참조 URL : https://stackoverflow.com/questions/27671390/why-inline-source-maps
'programing' 카테고리의 다른 글
| C에서 'char**'를 'const char* const*'로 변환할 수 없는 이유는 무엇입니까? (0) | 2022.07.02 |
|---|---|
| Task.Factory.StartNew 대 새 작업 (0) | 2021.01.15 |
| $ this에 대한 동적 참조는 작동하지 않지만 작동합니다. (0) | 2021.01.15 |
| UML 다이어그램을 GitLab 또는 GitHub에 통합하는 방법 (0) | 2021.01.15 |
| Java 9를 32 비트 OS에서 실행할 수 있습니까? (0) | 2021.01.15 |