Webpack 5.105 (2026-02-03)
Webpack 5.105는 코드 생성 및 버그 수정 측면에서 여러 가지 개선 사항을 제공합니다.
- Webpack에서 두 가지 낮은 심각도의 CVE 수정
- 플러그인 요구 없이
tsconfig.json별칭 해결 - 웹 워커에 대한 자동 모듈 해결
- 가져오기 지정자 가드 지원
- 컨텍스트 모듈에 대한
import.defer()지원 - 사용자 지정
import.meta속성 유지 - 개발 도구에서 소스 맵 제어 기능 향상
- [더 깔끔한 ESM 출력] Node.js 및 최신 빌드 환경 개선
- 기타 개선 사항 및 버그 수정
Two Low-Severity CVEs Fixed in Webpack
Webpack에서 발견된 심각도가 낮은 두 가지 CVE가 수정되어 게시되었습니다.
기본적으로는 안전하며, 이러한 문제는 실험적인 옵션인
experiments.buildHttp을 사용하는 사용자에게만 영향을 미칩니다.
Affected CVEs:
CVE-2025-68157
- 자세한 내용은 다음 보안 권고를 참고하세요: GHSA-38r7-794h-5758
- 영향을 받는 버전:
>=5.49.0 <5.104.0
CVE-2025-68458
- 자세한 내용은 GHSA-8fgc-7cc6-rx7x 보안 권고를 참고하세요.
- 영향을 받는 버전:
>=5.49.0 <5.104.1
이러한 CVE는 심각도가 낮지만, 영향을 받는 버전을 사용하는 경우 업데이트하는 것이 좋습니다.
보안 취약점 보고에 대한 자세한 내용은 Webpack 보안 정책을 참고하세요. .
tsconfig.json Alias Resolution Without Requiring plugins
모듈 해석은 tsconfig.json에서 compilerOptions.baseUrl과 compilerOptions.paths를 읽어와 임포트 해석 시 해당 별칭을 적용하도록 구성할 수 있습니다. 결과적으로, 번들링 중에 TypeScript 경로 별칭이 작동하도록 하기 위해 외부 tsconfig-paths-webpack-plugin을 설치하고 구성할 필요가 없어졌습니다.
webpack 설정에서 resolve.tsconfig 옵션은 소스로 사용할 tsconfig 파일을 지정하는 데 사용됩니다(이는 모노레포 또는 여러 개의 tsconfig 파일이 있는 환경에서도 유용합니다).
// webpack.config.js
module.exports = {
resolve: {
tsconfig: "./tsconfig.json", // `false`(비활성화), `true`(기본 tsconfig.json 사용), `tsconfig.json` 파일의 경로 또는 구성 파일 및 참조 옵션을 포함하는 객체일 수 있습니다.
},
};tsconfig.json 파일에 있는 별칭의 예시:
{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"@/*": ["src/*"]
}
}
}그리고 코드에는 다음과 같은 내용이 있습니다.
import Button from "@/components/Button";이렇게 하면 tsconfig.json에 정의된 규칙에 따라 @/components/Button을 해석할 수 있으므로 resolve.alias에 별칭을 중복해서 작성할 필요가 없고 TypeScript가 이해하는 것과 번들러가 해석하는 것 사이의 불일치를 줄일 수 있습니다.
Automatic Module Resolution for Web Workers
Webpack에서 웹 워커에서 사용할 패키지를 임포트할 때, package.json의 exports 필드에 조건부 내보내기(conditional exports)를 정의하면 모듈 해석 과정에서 index.js보다 index.worker.js와 같은 파일을 우선적으로 선택할 수 있습니다.
즉, 패키지의 exports 필드에 worker와 같은 조건을 정의하면 Webpack은 워커 컨텍스트 내에서 패키지를 임포트할 때마다 index.worker.js와 같은 적절한 버전을 자동으로 선택합니다. resolve.conditionNames 옵션을 수정하거나 추가적인 Webpack 설정을 변경할 필요 없이, package.json에 조건을 올바르게 지정하기만 하면 됩니다.
예를 들어, package.json에는 다음과 같이 조건을 정의합니다.
{
"name": "foo",
"exports": {
".": {
"worker": "./index.worker.js",
"default": "./index.js"
}
}
}이제 Worker 내부에서 foo 패키지를 임포트하면 Webpack은 내보내기 조건에 따라 자동으로 index.worker.js 파일을 선택합니다.
// 이 import 문은 Worker 컨텍스트 내부에 있으므로 Webpack은 index.worker.js를 사용합니다.
const worker = new Worker(new URL("foo", import.meta.url), {
type: "module",
});Support Import Specifier Guard
임포트 지정자 가드 지원이 추가되었습니다. 이 개선 사항은 번들러가 임포트를 사용하기 전에 임포트가 존재하는지 확인하는 일반적인 패턴을 더 잘 이해하도록 도와줍니다. 이전에는 if 문으로 코드를 올바르게 보호했더라도 접근이 무조건적인 것으로 해석되어 "… 내보낸 항목을 찾을 수 없습니다"와 같은 경고가 발생할 수 있었습니다.
이번 변경으로 이러한 검사는 접근이 조건부임을 나타내는 신호로 인식되어 분석이 그에 따라 조정됩니다. 실제로, 이를 통해 임포트가 존재할 수도 있고 존재하지 않을 수도 있는 동일한 라이브러리의 여러 버전에서 더 호환성이 높은 코드를 작성할 수 있으며, 컴파일 중에 불필요한 경고가 발생하지 않습니다.
import * as React from "react";
if (React.useId) {
// create guard for `React` => userId: ["", "useId"].
React.useId; // React -> "useId" is in guard.
React; // React -> "" is in guard.
}Support import.defer() for Context Module
Webpack은 이제 컨텍스트 모듈(즉, 임포트 경로가 동적으로 생성되고 Webpack이 여러 파일들을 포함해야 하는 경우)에서도 import.defer()를 지원합니다. 실제로 이 기능 덕분에 런타임에 선택된 모듈의 로딩을 훨씬 쉽게 지연시킬 수 있게 되었으며, 해당 모듈이 디렉터리를 가리키는 동적 표현식에서 가져온 경우에도 마찬가지입니다. 이를 통해 "a.js 또는 b.js 중에서 선택하고 필요할 때만 로드"와 같은 패턴을 구현할 수 있으며, Webpack은 import.defer()가 올바르게 작동하도록 적절한 컨텍스트를 생성합니다.
const file = Math.random() > 0.5 ? "a.js" : "b.js";
import.defer("./dir/" + file);
Preserving Custom import.meta Properties
Webpack은 이제 output.module(configuration/output/#outputmodule)이 활성화된 경우 번들링 과정에서 사용자 정의 import.meta 속성을 유지합니다. 이전에는 Webpack이 알 수 없는 import.meta 속성(예: import.meta.customProp)을 제거하여 빌드에서 컨텍스트 정보나 도구별 정보가 손실되는 문제가 있었습니다.
이번 변경으로 import.meta에 추가하는 모든 비표준 속성이 생성된 코드에 그대로 유지되므로 최신 애플리케이션에서 사용자 정의 메타 정보나 추가 신호를 활용할 수 있습니다.
if (!import.meta.UNKNOWN_PROPERTY) {
// runtime assignment
import.meta.UNKNOWN_PROPERTY = "HELLO";
}output.module이 활성화되어 있지 않으면 명시적으로 다른 설정을 하지 않는 한 Webpack은 알 수 없는 속성을 계속 제거합니다. 이러한 속성을 수동으로 유지하려면 webpack.config.js 파일에서 module.parser.javascript.importMeta를 'preserve-unknown'으로 설정할 수 있습니다.
// webpack.config.js
module.exports = {
module: {
parser: {
javascript: {
importMeta: "preserve-unknown",
},
},
},
};이렇게 하면 output.module: true가 없더라도 import.meta.customProp과 같은 모든 사용자 지정 import.meta 속성이 빌드에 유지됩니다.
Better Control of Source Maps in devtool
Webpack은 이제 devtool 옵션에서 고급 설정을 위해 문자열과 객체 배열을 모두 허용합니다.
배열의 각 객체에는 다음이 포함될 수 있습니다.
type:all,css, 또는javascript중 하나를 선택할 수 있습니다.use: 생성할 소스 맵의 유형을 정의합니다.
이를 통해 프로젝트의 각 리소스에 대해 서로 다른 유형의 소스 맵을 지정할 수 있습니다. 예를 들면 다음과 같습니다.
// webpack.config.js
module.exports = {
target: ["web", "node"],
experiments: {
css: true,
},
devtool: [
{
type: "javascript",
use: "source-map",
},
{
type: "css",
use: "inline-source-map",
},
],
};이 예제에서는 표준 소스 맵이 모든 모듈에 적용되고, 인라인 소스 맵은 CSS 파일에만 사용됩니다.
이 새로운 옵션은 특히 Webpack의 실험적인 CSS 컴파일 기능(/configuration/experiments/#experimentscss)을 사용하는 경우 유용합니다. 디버깅 과정을 더욱 세밀하게 제어할 수 있고 외부 도구와의 통합도 향상되기 때문입니다.
참고로, devtool: "source-map"과 같은 기존 문자열 구문도 여전히 유효하며 지원됩니다.
Cleaner ESM Output for Node.js and Modern Builds
Webpack의 이번 개선 사항은 특히 설정 파일에서 output.module 옵션을 사용할 때 Node.js 네이티브 모듈(예: fs, path, crypto)의 처리 및 표현을 최적화합니다. output.module: true 옵션을 활성화하면 Webpack은 이제 코드가 웹 환경에서 실행되든 Node.js 환경에서 실행되든 관계없이 CommonJS의 require("module") 구문 대신 ES 모듈 구문인 import ... from "module"을 사용하여 네이티브 모듈을 가져옵니다.
Other Improvements and Bug Fixes
- Webpack-dev-server가 새로운 버전으로 출시되어 이전에 보고된 전이적 취약점을 수정하는 종속성 업데이트가 이루어졌습니다. 따라서 업데이트를 권장합니다. 또한, ESC 키를 눌러 오류 오버레이를 닫을 수 있는 옵션이 추가되었고, 여러 버그가 수정되었습니다. 자세한 내용은 릴리스를 참고하세요.
- Webpack-bundle-analyzer의 사용자 경험이 크게 개선되고 버그가 수정되었습니다. 다크 모드에서 툴팁 관련 시각적 문제가 해결되었으며, IIFE를 사용한 번들 분석이 더욱 견고해져 오류가 발생하지 않도록 개선되었습니다. 또한, Node.js 22.15 이상에서만 사용 가능한 Zstandard 압축 지원이 추가되었습니다. 변경 로그에서 자세한 내용을 확인하세요.
- Mini-css-extract-plugin에 새로운 기능과 버그 수정 사항이 추가되었습니다. 주요 변경 사항으로는, 이제 플러그인이
output.cssFilename및output.cssChunkFilename옵션을 지원하여 생성된 CSS 파일의 이름을 더욱 정확하게 제어할 수 있게 되었습니다. 또한, CSS 모듈 세트의 크기가 0일 때 청크의contentHash가 생성되지 않던 버그가 수정되어 불필요한 해시 생성을 방지했습니다. 자세한 내용은 릴리스를 참고하세요.
버전 5.104 이후 여러 버그가 수정되었습니다. 자세한 내용은 변경 로그를 참고하세요.
Thanks
Webpack 5.105를 가능하게 해주신 모든 기여자분들과 후원자께 진심으로 감사드립니다. 코드 기여, 문서 작성, 재정적 후원 등 어떤 형태의 지원이든 Webpack이 모두를 위해 계속 발전하고 개선될 수 있도록 도와줍니다.

