Output Management | Webpack

이 가이드는 Asset Management 가이드에 있는 코드 예제를 기준으로 합니다.
지금까지 모든 애셋을 index.html 파일에 수동으로 포함했습니다. 하지만 애플리케이션이 커지면서 파일 이름에 해시를 사용하거나 다중 번들로 내보내기 시작하면 index.html 파일을 수동으로 관리하기 어렵습니다. 이 때 몇 가지 플러그인으로 이 프로세스를 훨씬 쉽게 관리할 수 있습니다.
먼저 프로젝트를 조금 수정해보겠습니다.
src/print.js 파일에 로직을 추가합니다.
그리고 src/index.js 파일에서 이 함수를 사용합니다.
webpack이 엔트리를 분할할 수 있도록 dist/index.html 파일도 업데이트해 보겠습니다.
이제 설정을 수정합니다. src/print.js를 새 엔트리 포인트(print)로 추가합니다. 그리고 출력 번들 이름이 엔트리 포인트 이름을 기반으로 동적으로 생성되도록 변경합니다.
npm run build를 실행하고 무엇이 생성되는지 살펴보겠습니다.
webpack이 print.bundle.js 과 index.bundle.js 파일을 생성하는 것을 볼 수 있습니다. 이 파일은 index.html 파일에도 명시되어 있습니다. 브라우저에서 index.html을 열고 버튼을 클릭하면 어떻게 되는지 확인할 수 있습니다.
그러나 엔트리 포인트 중 하나의 이름을 변경하거나 새 엔트리 포인트를 추가하면 어떻게 될까요? 생성된 번들은 빌드에서 이름이 변경되지만 index.html 파일은 여전히 예전 이름을 참조합니다. HtmlWebpackPlugin을 사용하여 이 문제를 해결해보겠습니다.
print.bundle.js 파일을 검사해 보면 printMe 함수가 없는 것을 알 수 있습니다. 대신, 눈에 띄는 부작용이 없는 즉시 실행 함수 표현식(IIFE)만 포함되어 있습니다. 이는 현재 설정에서 webpack이 각 진입점을 번들이 로드될 때 실행되는 독립 실행형 프로그램으로 취급하기 때문입니다. print.js는 함수만 내보내고 printMe()를 호출하지 않으므로, 자체 진입점으로 실행하는 데 실행 가능한 런타임 코드가 필요하지 않습니다. 따라서 눈에 띄는 부작용이 없으므로 해당 코드를 최적화로 생략할 수 있습니다. 반면, index.js는 printMe를 가져와 사용하므로 webpack은 index.bundle.js에 해당 함수를 직접 포함합니다. Webpack은 모듈 번들러이므로 index.bundle.js 파일에는 해결되지 않은 import 문 대신 실행에 필요한 모든 코드가 포함되어 있다는 점을 기억하세요. 여기서는 출력 관리 및 HtmlWebpackPlugin을 시연하기 위해 여러 진입점을 사용했습니다. 실제 프로젝트에서는 일반적으로 이와 같은 유틸리티 모듈에 대해 별도의 진입점을 만들지 않습니다. 종속성을 공유하는 여러 진입점이 있는 경우 코드 분할 가이드의 중복 방지를 참고하세요.
Webpack은 output.html로 페이지를 직접 생성할 수 있습니다. Native HTML을 참고하세요. 이 가이드에서는 생성된 페이지가 내부 청크 이름으로 엔트리 script를 다시 추가하여 여기서 다루는 번들 파일 이름을 알아보기 어렵게 하므로 HtmlWebpackPlugin을 계속 사용합니다.
먼저 plugin을 설치하고 webpack.config.js 파일을 수정합니다.
빌드하기 전에 dist/ 폴더에 이미 index.html이 있더라도 기본적으로 HtmlWebpackPlugin이 자체 index.html 파일을 생성하는 것을 알아두세요. 이는 index.html 파일이 새로 생성된 파일로 대체된다는 의미입니다. npm run build를 실행할 때 어떤 일이 발생하는지 살펴보겠습니다.
코드 편집기에서 index.html을 열면 HtmlWebpackPlugin이 완전히 새로운 파일을 생성했으며 모든 번들이 자동으로 추가된 것을 알 수 있습니다.
HtmlWebpackPlugin이 제공하는 모든 기능과 옵션에 대해 더 자세히 알아보려면 HtmlWebpackPlugin 저장소를 확인해 보세요.
이전 가이드와 코드 예제에서 눈치챘겠지만 /dist 폴더가 상당히 복잡해졌습니다. webpack은 파일을 생성하여 /dist 폴더에 저장하지만, 프로젝트에서 실제로 사용하는 파일이 어떤 건지는 알지 못합니다.
일반적으로 사용하는 파일만 생성되도록 각 빌드 전에 /dist 폴더를 정리하는 것이 좋습니다. output.clean 옵션을 사용하여 처리해보겠습니다.
이제 npm run build를 실행하고 /dist 폴더를 확인해보세요. 모든 것이 잘 되었다면 이제 오래된 파일 없이 빌드에서 생성된 파일만 볼 수 있습니다!
webpack과 플러그인은 어떤 파일이 생성되는 것을 어떻게 "알고 있는지" 궁금할 것입니다. 답은 매니페스트에 있습니다. webpack은 모든 모듈이 출력 번들에 어떻게 매핑되는지 추적합니다. 만약 webpack의 output을 다른 방식으로 관리하는데 관심이 있다면 매니페스트부터 시작하는 것이 좋습니다.
매니페스트 데이터는 ManifestPlugin을 사용하여 쉽게 적용 가능한 json 파일로 추출할 수 있습니다.
프로젝트에서 이 플러그인을 사용하는 방법에 대한 모든 예제를 다루지는 않겠지만 콘셉 페이지 및 캐싱 가이드를 읽어 보면 이것이 장기 캐싱과 어떻게 연결되는지 확인할 수 있습니다.
HTML에 번들을 동적으로 추가하는 방법을 배웠으므로 이제 개발 가이드를 살펴보세요. 또는 심화 항목을 자세히 알아보고 싶다면 코드 스플리팅 가이드를 추천합니다.
저작권은 OpenJS Foundation 및 webpack 기여자에게 있으며, 모든 권리는 보호됩니다. OpenJS Foundation은 등록 상표를 보유하고 있으며 상표를 사용합니다. OpenJS Foundation의 상표 목록은 Trademark Policy와 Trademark List에서 확인할 수 있습니다. OpenJS Foundation 상표 목록에 표시되지 않은 상표 및 로고는 각 소유자의 상표™ 또는 등록 상표®입니다. 이를 사용한다고 해서 해당 소유자와의 제휴 관계나 보증을 의미하지는 않습니다.
The OpenJS Foundation | Terms of Use | Privacy Policy | Bylaws | Code of Conduct | Trademark Policy | Trademark List | Cookie Policy