Other Options

webpack에서 지원하는 나머지 설정 옵션들이 있습니다.

amd

object false

require.amd 또는 define.amd의 값을 설정합니다. amd를 false로 설정하면 webpack AMD 지원이 비활성화됩니다.

webpack.config.js

export default {
  // ...
  amd: {
    jQuery: true,
  },
};

jQuery 1.7.0 ~ 1.9.1 같이 AMD로 작성된 특정 인기 모듈은 로더가 페이지에 포함되는 여러 버전에 대해 특별한 허용을 받았다고 표시하는 경우에만 AMD 모듈로 등록됩니다.

허용되는 기능은 등록을 특정 버전으로 제한하거나 정의된 모듈이 다른 다양한 샌드박스를 지원하는 기능이었습니다.

이 옵션을 사용하면 모듈이 찾는 키를 정확한 값으로 설정할 수 있습니다. 이 경우 webpack의 AMD 지원은 정의된 이름을 무시합니다.

bail

boolean = false

넘어가지 않고 첫 번째 오류에서 실패합니다. 기본적으로 webpack은 HMR을 사용할 때 브라우저 콘솔뿐만 아니라 터미널에 이러한 오류를 빨간색으로 기록하지만 번들링을 계속합니다. 아래와 같이 활성화합니다.

webpack.config.js

export default {
  // ...
  bail: true,
};

이렇게 하면 webpack은 번들링 프로세스를 종료합니다.

dependencies

string[]

의존하는 모든 형제 설정을 정의하는 name 목록입니다. 먼저 의존하는 설정을 컴파일해야 합니다.

감시 모드에서 디펜던시는 다음과 같은 경우 컴파일러를 무효화합니다.

디펜던시가 변경된 경우
디펜던시가 현재 컴파일 중이거나 유효하지 않은 경우

현재 설정은 의존하는 디펜던시가 완료될 때까지 컴파일되지 않습니다.

webpack.config.js

export default [
  {
    name: "client",
    target: "web",
    // …
  },
  {
    name: "server",
    target: "node",
    dependencies: ["client"],
  },
];

ignoreWarnings

(RegExp | { module?: RegExp, file?: RegExp, message?: RegExp } | ((warning: WebpackError, compilation: Compilation) => boolean))[]

특정 경고를 무시하도록 webpack에 지시합니다. 이것은 WebpackError 및 Compilation을 인수로 받고 boolean를 반환하는 원시 경고 인스턴스를 기반으로 경고를 선택하는 커스텀 function, RegExp 그리고 아래의 프로퍼티를 가지는 object가 될 수 있습니다.

file : 경고에 대한 원본 파일을 선택하는 RegExp입니다.
message : 경고 메시지를 선택하는 RegExp입니다.
module : 경고에 대한 원본 모듈을 선택하는 RegExp입니다.

ignoreWarnings은 위의 항목 일부 또는 전체를 갖는 배열이어야 합니다.

export default {
  // ...
  ignoreWarnings: [
    {
      module: /module2\.js\?[34]/, // A RegExp
    },
    {
      module: /[13]/,
      message: /homepage/,
    },
    /warning from compiler/,
    (warning) => true,
  ],
};

loader

object

사용자 정의 값을 loader context에 노출합니다.

예를들면, loader context에 새 변수를 정의할 수 있습니다.

webpack.config.js

export default {
  // ...
  loader: {
    answer: 42,
  },
};

그런 다음 로더에서 이 값을 가져오기 위해 this.answer를 사용하세요.

custom-loader.js

export default function (source) {
  // ...
  console.log(this.answer); // `42`를 기록합니다.
  return source;
}

name

string

설정의 이름입니다. 여러 설정을 로드할 때 사용됩니다.

This is especially useful when exporting an array of configurations. webpack uses name to identify each config in logs and stats output.

webpack.config.js

export default {
  // ...
  name: "admin-app",
};

For multi-configuration builds:

export default [
  {
    name: "client",
    target: "web",
    // ...
  },
  {
    name: "server",
    target: "node",
    // ...
  },
];

parallelism

number = 100

병렬 처리되는 모듈의 수를 제한하세요. 성능을 미세하게 조정하거나 보다 안정적인 프로파일링 결과를 얻는 경우 사용할 수 있습니다.

Lower values reduce concurrent work and memory pressure, but may increase total build time. Higher values can improve throughput on powerful machines.

webpack.config.js

export default {
  // ...
  parallelism: 50,
};

Use cases:

Reduce parallelism when builds hit memory limits (for example in constrained CI runners).
Increase it when you have enough CPU and memory and want to maximize build throughput.

profile

boolean

통계 및 힌트를 포함하여 애플리케이션의 "프로필"을 캡처 한 다음 분석 도구를 사용하여 분석 할 수 있습니다. 또한 모듈 타이밍에 대한 요약도 기록합니다.

webpack.config.js

export default {
  // ...
  profile: true,
};

recordsInputPath

string

마지막 레코드 세트를 읽을 파일을 지정하세요. 레코드 파일의 이름을 바꾸는 데 사용할 수 있습니다. 아래 예제를 참고하세요.

When this option is set, webpack reads previously generated records from this path and uses them as input for stable module/chunk id tracking.

webpack.config.js

import path from "node:path";
import { fileURLToPath } from "node:url";

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

export default {
  // ...
  recordsInputPath: path.join(__dirname, "records.json"),
  recordsOutputPath: path.join(__dirname, "records-next.json"),
};

recordsOutputPath

string

레코드를 작성해야하는 위치를 지정하세요. 다음 예제는 이 옵션을 recordsInputPath와 함께 사용하여 레코드 파일의 이름을 바꾸는 방법을 보여줍니다.

webpack.config.js

import path from "node:path";
import { fileURLToPath } from "node:url";

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

export default {
  // ...
  recordsInputPath: path.join(__dirname, "records.json"),
  recordsOutputPath: path.join(__dirname, "newRecords.json"),
};

recordsPath

string

이 옵션을 사용하여 여러 빌드에서 모듈 식별자를 저장하는 경우 사용되는 데이터 조각인 webpack "레코드"를 포함하는 JSON 파일을 생성합니다. 이 파일을 사용하여 빌드간에 모듈이 변경되는 방식을 추적할 수 있습니다. 생성하려면 위치를 지정하기 만하면 됩니다.

webpack.config.js

import path from "node:path";
import { fileURLToPath } from "node:url";

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

export default {
  // ...
  recordsPath: path.join(__dirname, "records.json"),
};

레코드는 코드 스플리팅을 활용하는 복잡한 설정이 있는 경우 특히 유용합니다. 분할된 번들이 필요한 캐싱 동작을 달성하는지 확인할 수 있습니다.

snapshot

object

snapshot 옵션은 파일 시스템 스냅샷을 만들고 무효화하는 방법을 결정합니다.

webpack.config.js

import path from "node:path";
import { fileURLToPath } from "node:url";

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

export default {
  // ...
  snapshot: {
    managedPaths: [path.resolve(__dirname, "../node_modules")],
    immutablePaths: [],
    unmanagedPaths: [],
    buildDependencies: {
      hash: true,
      timestamp: true,
    },
    module: {
      timestamp: true,
    },
    contextModule: {
      hash: true,
      timestamp: true,
    },
    resolve: {
      timestamp: true,
    },
    resolveBuildDependencies: {
      hash: true,
      timestamp: true,
    },
  },
};

buildDependencies

{ hash?: boolean = true, timestamp?: boolean = true }

영구 캐시를 사용할 때 빌드 디펜던시에 대한 스냅샷입니다.

hash: 콘텐츠 해시를 비교하여 무효화를 확인합니다(timestamp보다 비용이 많이 들지만 자주 변경되지 않음).
timestamp: 타임 스탬프를 비교하여 무효화를 확인합니다.

hash와 timestamp 모두 선택사항입니다.

{ hash: true }: 타임 스탬프를 유지하지 않고 해시를 사용하는 새로운 체크 아웃으로 CI 캐싱에 적합합니다.
{ timestamp: true }: 로컬 개발 캐싱에 적합합니다.
{ timestamp: true, hash: true }: 위에서 언급 한 두 경우 모두 좋습니다. 타임 스탬프가 먼저 비교되는데, 이는 webpack이 해시를 계산하기 위해 파일을 읽을 필요가 없기 때문에 비용이 저렴합니다. 콘텐츠 해시는 타임 스탬프가 동일한 경우에만 비교되므로 초기 빌드에서 약간의 성능 저하가 발생합니다.

immutablePaths

(RegExp | string)[]

패키지 관리자가 관리하고 경로에 버전 또는 해시를 포함하여 모든 파일을 변경할 수 없는 경로 배열입니다.

webpack은 이 경로 아래의 파일에 대해 타임스탬프, 콘텐츠 해시 등 아무것도 기록하지 않으며 다시 확인하지 않습니다. 패키지 버전이 경로의 일부인 Yarn Plug'n'Play의 zip 캐시처럼 콘텐츠가 변경될 때마다 경로 자체가 변경되는 디렉터리에 사용하세요. 불변 경로 아래의 파일을 편집해도 해당 파일로 빌드된 것은 무효화되지 않습니다.

정규식은 경로에 대해서만 테스트되므로 캡처 그룹이 필요하지 않습니다.

managedPaths

(RegExp | string)[]

패키지 관리자가 관리하고 수정되지 않도록 신뢰할 수 있는 경로의 배열입니다.

이 경로 아래의 파일에 대해 webpack은 파일 자체를 스냅샷하지 않습니다. 대신 파일이 포함된 패키지 디렉터리를 확인하고 해당 디렉터리의 package.json에서 읽은 name@version을 기록합니다. 해당 문자열이 변경되면(패키지 관리자가 다른 버전을 설치할 때) 패키지로부터 빌드된 모든 것이 무효화되며, 패키지 내부 파일을 직접 편집했을 때는 무효화되지 않습니다. 이것이 immutablePaths와의 차이입니다. 관리 경로는 모든 빌드에서 재확인되지만 파일마다가 아닌 패키지마다 한 번씩 확인됩니다.

즉, node_modules의 파일을 직접 편집하거나 도구가 버전을 변경하지 않고 설치 후 패치하면 webpack은 캐시된 결과를 계속 사용합니다. 이러한 패키지는 unmanagedPaths 아래에 나열하거나(또는 아래와 같이 managedPaths를 좁혀서) 파일들이 개별적으로 스냅샷되도록 하세요.

패키지가 포함된 디렉터리가 정규식의 첫 번째 캡처 그룹에 래핑되어 있는지 확인하세요. 그래야 webpack이 이를 추출할 수 있습니다. 예를 들어 webpack 내부적으로 node_modules 디렉터리를 일치시키는 데 사용하는 RegExp는 다음과 같습니다.

/^(.+?[\\/]node_modules[\\/])/

캡처 그룹에는 후행 슬래시가 포함되어야 합니다. 없으면 webpack은 내부 패키지 디렉터리 대신 node_modules 디렉터리 자체를 관리 항목으로 처리합니다.

managedPaths의 일반적인 사용 사례는 node_modules에서 일부 폴더를 제외하는 것입니다. 예를 들어, node_modules/@azure/msal-browser 폴더의 파일이 변경될 것으로 예상된다는 것을 webpack에 알리고자 합니다. 이는 아래와 같은 정규식으로 수행할 수 있습니다.

export default {
  snapshot: {
    managedPaths: [
      /^(.+?[\\/]node_modules[\\/](?!(@azure[\\/]msal-browser))(@.+?[\\/])?.+?)[\\/]/,
    ],
  },
};

unmanagedPaths

5.90.0+

(RegExp | string)[]

패키지 관리자가 관리하지 않는 경로의 배열과 내용은 변경될 수 있습니다.

immutablePaths 및 managedPaths보다 먼저 확인되므로, 예를 들어 node_modules 내부의 링크된 패키지처럼 해당 경로에서 디렉터리를 제외하는 방법입니다. 관리되지 않는 경로 아래의 파일은 snapshot.module 및 snapshot.resolve에 따라 개별적으로 스냅샷됩니다.

정규식은 경로에 대해서만 테스트되므로 캡처 그룹이 필요하지 않습니다.

module

{ hash?: boolean, timestamp?: boolean = true }

모듈 빌드를 위한 스냅샷입니다. production 모드에서는 기본값이 { timestamp: true, hash: true }입니다.

hash: 콘텐츠 해시를 비교하여 무효화를 확인합니다(timestamp보다 비용이 많이 들지만 자주 변경되지 않음).
timestamp: 타임 스탬프를 비교하여 무효화를 확인합니다.

contextModule

{ hash?: boolean, timestamp?: boolean = true }

컨텍스트 모듈을 구축하기 위한 스냅샷.

resolve

{ hash?: boolean, timestamp?: boolean = true }

요청 해석을 위한 스냅샷입니다. production 모드에서는 기본값이 { timestamp: true, hash: true }입니다.

hash: 콘텐츠 해시를 비교하여 무효화를 확인합니다(timestamp보다 비용이 많이 들지만 자주 변경되지 않음).
timestamp: 타임 스탬프를 비교하여 무효화를 확인합니다.

resolveBuildDependencies

{ hash?: boolean = true, timestamp?: boolean = true }

영구 캐시를 사용할 때 빌드 디펜던시를 해석하기위한 스냅샷입니다.

hash: 콘텐츠 해시를 비교하여 무효화를 확인합니다(timestamp보다 비용이 많이 들지만 자주 변경되지 않음).
timestamp: 타임 스탬프를 비교하여 무효화를 확인합니다.

15 Contributors

Translators

YukJiSoo

Other Options

amd

bail

dependencies

ignoreWarnings

loader

name

parallelism

profile

recordsInputPath

recordsOutputPath

recordsPath

snapshot

buildDependencies

immutablePaths

managedPaths

unmanagedPaths

module

contextModule

resolve

resolveBuildDependencies

Further Reading

15 Contributors

Translators