AutomaticPrefetchPlugin

AutomaticPrefetchPlugin은 변경사항을 관찰하는 동안 이전 컴파일의 모든 모듈을 미리 검색하여 증가하는 빌드 시간을 개선합니다. 단일 모듈을 미리 검색하는 PrefetchPlugin 과 비교해보세요.

webpack.config.js

export default {
  // ...
  plugins: [new webpack.AutomaticPrefetchPlugin()],
};

BannerPlugin

생성된 각 청크의 상단에 배너를 추가합니다.

import webpack from "webpack";

new webpack.BannerPlugin(banner);
// 또는
new webpack.BannerPlugin(options);

Options

{
  banner: string | function, // 배너를 문자열 또는 함수로 사용하면, 주석으로 감싸집니다.
  raw: boolean, // true이면, 배너가 주석에 감싸지지 않습니다.
  entryOnly: boolean, // true이면, 배너는 엔트리 청크에만 추가됩니다.
  test: string | RegExp | [string, RegExp], // 테스트를 통과하는 모든 모듈이 포함됩니다.
  include: string | RegExp | [string, RegExp], // 다음 조건 중 하나라도 일치하는 모든 모듈이 포함됩니다.
  exclude: string | RegExp | [string, RegExp], // 다음 조건 중 하나라도 일치하는 모든 모듈이 제외됩니다.
  footer?: boolean, // true이면, 배너는 컴파일이 끝날 때 배치됩니다.
  stage?: number, // 배너를 주입해야 하는 컴파일 단계
}

Usage

import webpack from "webpack";

// 문자열
new webpack.BannerPlugin({
  banner: "hello world",
});

// 함수
new webpack.BannerPlugin({
  banner: (yourVariable) => `yourVariable: ${yourVariable}`,
});

// 최소화 및 애셋 조작 후 배너 메시지를 추가합니다.
new webpack.BannerPlugin({
  raw: true,
  banner: "/* 배너는 문자열입니다 */",
  stage: webpack.Compilation.PROCESS_ASSETS_STAGE_REPORT,
});

Placeholders

webpack 2.5.0 부터, placeholder는 배너 문자열로 평가됩니다.

import webpack from "webpack";

new webpack.BannerPlugin({
  banner:
    "fullhash:[fullhash], chunkhash:[chunkhash], name:[name], base:[base], query:[query], file:[file]",
});

ChunksWebpackPlugin

The chunks-webpack-plugin creates HTML files with entry points and chunks relations to serve your webpack bundles. It is suitable with multi-page applications that contain multiple entry points.

Since webpack 4, SplitChunksPlugin offers the possibility to optimizes all chunks. It can be particularly powerful, because it means that chunks can be shared even between async and non-async chunks. See the webpack documentation of splitChunks.chunks for details.

splitChunks.chunks option can be set to automatically generate new chunks associated with an entry point. For example, entry points a.js and b.js share common code with the file vendors~a~b.js.

With multiple entry points, it can be difficult to identify relation between the auto-generated chunks and entry points.

chunks-webpack-plugin parses the webpack compilation entry points to get all files associated with the entry points. Then, it generates HTML files which include all assets filtered by an entry point and thechunks-manifest.json file.

Zero configuration

It works without configuration. For advanced usage, see the using configuration section.

Installation

chunks-webpack-plugin is available on npm as chunks-webpack-plugin and as chunks-webpack-plugin on GitHub.

npm install chunks-webpack-plugin --save-dev

yarn add chunks-webpack-plugin --dev

[!WARNING] Plugin chunks-webpack-plugin@10 is ESM only. [!NOTE] Minimum supported Node.js version is 16.20.0 and Webpack >=5.10.3.

Example

The project includes a minimalist example in the ./example directory. Run the npm run build:example command to execute the Webpack example and see the plugin's implementation in action.

Basic usage

chunks-webpack-plugin will generate two HTML files for each entry point. Each filename contains the entry point name, the {{entry}} placeholder is automatically replaced.

• {{entry}}-styles.html: contains all HTML <link> tags
• {{entry}}-scripts.html: contains all HTML <script> tags

First, let's add the plugin to the webpack configuration.

webpack.config.js

import ChunksWebpackPlugin from 'chunks-webpack-plugin';

export default {
  plugins: [new ChunksWebpackPlugin()]
};

HTML files are built in the output path directory with the rest of the webpack compilation.

Now you can include the generated HTML files into your HTML page templates. You can do it with e.g. Twig.

main-styles.html

<link rel="stylesheet" href="main.css" />

main-scripts.html

<script defer src="main.js"></script>

Using a configuration

You can pass a configuration object to chunks-webpack-plugin to override the default settings.

filename

Type:

type filename = string;

Default: '[name]-[type].html'

Tells the plugin whether to personalize the filename of the generated files. Files are processed by the webpack compilation and generated in the output path directory. The placeholder [name] is automatically replaced by entry points names and [type] by styles|scripts.

new ChunksWebpackPlugin({
  filename: 'templates/[name]-[type].html'
});

[!NOTE] The filename can contain directories, which will be created automatically.

templateStyle

Type:

type templateStyle = (name: string, entryName: string) => string;

Default:

(name) => `<link rel="stylesheet" href="${name}" />`;

Tells the plugin whether to personalize the default template for the HTML <style> tags. For example, add additional attributes or a CDN prefix.

export default {
  plugins: [
    new ChunksWebpackPlugin({
      templateStyle: (name) => `<link rel="stylesheet" href="https://cdn.domain.com${name}" />`
    })
  ]
};

templateScript

Type:

type templateScript = (name: string, entryName: string) => string;

Default:

(name) => `<script defer src="${name}"></script>`;

Tells the plugin whether to personalize the default template for the HTML <script> tags. For example, add additional attributes or a CDN prefix.

export default {
  plugins: [
    new ChunksWebpackPlugin({
      templateScript: (name) => `<script defer src="https://cdn.domain.com${name}"></script>`
    })
  ]
};

generateChunksManifest

Type:

type generateChunksManifest = boolean;

Default: false

Tells the plugin whether to generate the chunks-manifest.json. The file contains the list of all chunks grouped by entry points. See the chunks-manifest.json example.

export default {
  plugins: [
    new ChunksWebpackPlugin({
      generateChunksManifest: true
    })
  ]
};

generateChunksFiles

Type:

type generateChunksFiles = boolean;

Default: true

Tells the plugin whether to generate the HTML files.

export default {
  plugins: [
    new ChunksWebpackPlugin({
      generateChunksFiles: false
    })
  ]
};

[!WARNING] When set to false, HTML files will not be generated. It can only be useful together with generateChunksManifest option set to true for custom generation of the HTML files.

import ChunksWebpackPlugin from 'chunks-webpack-plugin';
import path from 'node:path';

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

export default {
  entry: {
    home: 'home.js',
    news: 'news.js'
  },
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, './dist')
  },
  plugins: [new ChunksWebpackPlugin()],
  optimization: {
    splitChunks: {
      chunks: 'all'
    }
  }
};

<link rel="stylesheet" href="vendors~home~news.css" />
<link rel="stylesheet" href="home.css" />

<script defer src="vendors~home~news.js"></script>
<script defer src="home.js"></script>

<link rel="stylesheet" href="vendors~home~news.css" />
<link rel="stylesheet" href="news.css" />

<script defer src="vendors~home~news.js"></script>
<script defer src="news.js"></script>

License

chunks-webpack-plugin is licensed under the MIT License.

Created with ♥ by @yoriiis.

CommonsChunkPlugin

CommonsChunkPlugin은 여러 엔트리 포인트 간에 공유되는 공통 모듈로 이루어진 별도의 파일(청크라고 합니다)을 만드는 opt-in 기능입니다.

번들에서 공통 모듈을 분리한 결과로 생성된 청크 파일을 처음에 한 번 로드하고 나중에 사용하기 위해 캐시에 저장할 수 있습니다. 이로 인해 브라우저가 새 페이지를 방문할 때마다 더 큰 번들을 로드하지 않고 캐시에서 공유 코드를 빠르게 제공할 수 있으므로 페이지 속도가 최적화됩니다.

new webpack.optimize.CommonsChunkPlugin(options);

Options

{
  name: string, // 또는
  names: string[],
  // 공통 청크의 청크 이름입니다. 청크의 이름을 전달하여 기존 청크를 선택할 수 있습니다.
  // 문자열 배열로 전달되면 각 청크 이름에 대해 플러그인을 여러 번 호출하는 것과 같습니다.
  // 생략하면 `options.async` 또는 `options.children`이 설정되고 모든 청크가 사용됩니다.
  // 그렇지 않으면 청크 이름으로 사용되는 `options.filename`이 사용되게 됩니다.
  // `options.async`를 사용하여 다른 비동기 청크에서 공통 청크를 만들 때 `option.name`을 생략하는 대신 여기에
  // 엔트리 포인트 청크 이름을 지정해야 합니다.

  filename: string,
  // 공통 청크의 파일 이름 템플릿입니다. `output.filename`과 동일한 플레이스홀더를 포함할 수 있습니다.
  // 생략하면 원본 파일 이름은 수정되지 않습니다(일반적으로 `output.filename` 혹은 `output.chunkFilename`).
  // 이 옵션은 `options.async`를 사용하는 경우에도 허용되지 않습니다. 자세한 내용은 아래를 참조하세요.

  minChunks: number|Infinity|function(module, count) => boolean,
  // 공통 청크로 이동하기 전에 모듈을 포함해야 하는 최소 청크 수입니다.
  // 숫자는 2보다 크거나 같고 청크 수보다 작거나 같아야 합니다.
  // `Infinity`를 전달하면 공통 청크가 생성되지만 모듈은 이동하지 않습니다.
  // `function`을 제공하여 맞춤 로직을 추가 할 수 있습니다.(기본값은 청크의 수입니다)

  chunks: string[],
  // 청크 이름으로 소스 청크를 선택합니다. 청크는 공통 청크의 자식이어야 합니다.
  // 생략하면 모든 엔트리 청크가 선택됩니다.

  children: boolean,
  // `true`이면 공통 청크의 모든 자식이 선택됩니다.

  deepChildren: boolean,
  // `true`이면 공통 청크의 모든 자손이 선택됩니다.

  async: boolean|string,
  // `true`이면 새로운 비동기 공통 청크가 `options.name`의 하위 항목 및 `options.chunks`와 동등한 항목으로 생성됩니다.
  // `options.chunks`와 병렬로 로드됩니다.
  // `option.filename`을 사용하는 대신 `true`가 아닌 원하는 문자열을 제공해
  // 출력 파일의 이름을 변경할 수 있습니다.

  minSize: number,
  // 공통 청크가 생성되기 전 모든 공통 모듈의 최소 사이즈입니다.
}

Examples

Commons chunk for entries

엔트리 포인트 간에 공유되는 공통 모듈을 포함하는 추가 청크를 생성합니다.

new webpack.optimize.CommonsChunkPlugin({
  name: "commons",
  // (공통 청크 이름)

  filename: "commons.js",
  // (공통 청크의 파일 이름)

  // minChunks: 3,
  // (모듈은 최소 3개의 엔트리 사이에서 공유해야 합니다)

  // chunks: ["pageA", "pageB"],
  // (이 엔트리에서만 사용됩니다)
});

생성된 청크는 엔트리 포인트 전에 로드해야 합니다.

<script src="commons.js" charset="utf-8"></script>
<script src="entry.bundle.js" charset="utf-8"></script>

Explicit vendor chunk

코드를 vendor와 애플리케이션으로 분할합니다.

module.exports = {
  // ...
  entry: {
    vendor: ["jquery", "other-lib"],
    app: "./entry",
  },
  plugins: [
    new webpack.optimize.CommonsChunkPlugin({
      name: "vendor",
      // filename: "vendor.js"
      // (청크에 다른 이름을 지정하세요)

      minChunks: Infinity,
      // (엔트리가 더 많으면 다른 모듈이 vendor 청크로
      //  들어가지 않습니다)
    }),
  ],
};

<script src="vendor.js" charset="utf-8"></script>
<script src="app.js" charset="utf-8"></script>

Move common modules into the parent chunk

Code Splitting을 사용하면 엔트리 청크의 여러 하위(자식) 청크가 공통 종속성을 가질 수 있습니다. 중복을 방지하기 위해 이들을 부모 청크로 옮길 수 있습니다. 이렇게 하면 전체 크기가 줄어들지만, 초기 로드 시간에 부정적인 영향을 미칩니다. 사용자가 많은 형제 청크(예: 엔트리 청크의 자식)를 다운로드해야 할 것으로 예상되는 경우 전체 로드 시간이 향상됩니다.

new webpack.optimize.CommonsChunkPlugin({
  // names: ["app", "subPageA"]
  // (청크를 선택하거나 모든 청크를 생략하세요)

  children: true,
  // (선택된 청크의 모든 자식을 선택합니다)

  // minChunks: 3,
  // (모듈을 옮기기 전에 3명의 자식이 공유해야 합니다)
});

Extra async commons chunk

위의 것과 유사하지만 공통 모듈을 부모로 이동하는 대신(초기 로드 시간을 증가시키게 됩니다) 비동기식으로 로드된 새로운 추가 공통 청크가 사용됩니다. 이는 추가 청크가 다운로드되면 자동으로 병렬로 다운로드됩니다.

new webpack.optimize.CommonsChunkPlugin({
  name: "app",
  // 또는
  names: ["app", "subPageA"],
  // 단일 이름 또는 배열 형태의 이름은 비동기 청크를 생성하는
  // 엔트리 포인트의 이름과 일치해야 합니다.

  children: true,
  // (청크의 모든 자식을 사용합니다)

  async: true,
  // (비동기 공통 청크를 생성합니다)

  minChunks: 3,
  // (모듈이 분리되기 전에 3명의 자식이 모듈을 공유해야 합니다)
});

Passing the minChunks property a function

또한 minChunks 속성에 함수를 전달할 수도 있습니다. 이 함수는 CommonsChunkPlugin에 의해 호출되며 module 및 count 인수로 함수를 호출합니다.

module 인수는 name/names 속성을 통해 제공된 청크의 각 모듈을 나타냅니다. module은 NormalModule의 형태로, 이 사용 사례에 특히 유용한 두 개의 속성이 있습니다.

• module.context: 파일을 저장하는 디렉터리입니다. 예: '/my_project/node_modules/example-dependency'
• module.resource: 처리중인 파일의 이름입니다. 예: '/my_project/node_modules/example-dependency/index.js'

count 인수는 module이 사용되는 청크 수를 나타냅니다.

이 옵션은 CommonsChunk 알고리즘을 통해 모듈을 이동할 위치를 결정하는 방법을 세밀하게 제어하려는 경우에 유용합니다.

new webpack.optimize.CommonsChunkPlugin({
  name: "my-single-lib-chunk",
  filename: "my-single-lib-chunk.js",
  minChunks(module, count) {
    // 모듈이 경로를 가지고 있고 경로에 "somelib"이 존재하고
    // 3개의 개별 청크/엔트리에서 사용되는 경우
    // 청크의 키 이름이 "my-single-lib-chunk", 파일 이름이 "my-single-lib-chunk.js"로 분할됩니다.
    return module.resource && /somelib/.test(module.resource) && count === 3;
  },
});

위에서 볼 수 있듯이 이 예제를 사용하면 함수 내의 모든 조건이 충족되는 경우에만, 하나의 라이브러리를 별도의 파일로 이동할 수 있습니다.

이 개념은 암시적 공통 vendor 청크를 얻는데 사용할 수 있습니다.

new webpack.optimize.CommonsChunkPlugin({
  name: "vendor",
  minChunks(module) {
    // 이는 vendor의 import가 node_modules 디렉터리에 존재한다고 가정합니다.
    return module.context && module.context.includes("node_modules");
  },
});

Manifest file

webpack 부트스트랩 로직을 별도의 파일로 추출하려면 entry로 정의되어 있지 않은 name에 CommonsChunkPlugin을 사용하세요. 자세한 내용은 캐싱 가이드를 참조하세요.

new webpack.optimize.CommonsChunkPlugin({
  name: "manifest",
  minChunks: Infinity,
});

Combining implicit common vendor chunks and manifest file

vendor와 manifest 청크는 minChunks에 대해 다른 정의를 사용하므로 플러그인을 두 번 호출해야 합니다.

[
  new webpack.optimize.CommonsChunkPlugin({
    name: "vendor",
    minChunks(module) {
      return module.context && module.context.includes("node_modules");
    },
  }),
  new webpack.optimize.CommonsChunkPlugin({
    name: "manifest",
    minChunks: Infinity,
  }),
];

More Examples

• 공통 및 Vendor 청크
• 다중 공통 청크
• 공통 청크가 있는 다중 엔트리 포인트

ContextExclusionPlugin

Context는 require('./locale/' + name + '.json')와 같은 import() 또는 require()의 동적 표현식을 의미합니다.

ContextExclusionPlugin을 사용하면 컨텍스트를 제외할 수 있습니다. 정규 표현식과 일치하는 모든 컨텍스트를 제외하려면 플러그인을 초기화할 때 정규 표현식을 인수로 제공하세요.

webpack.config.js

export default {
  plugins: [new webpack.ContextExclusionPlugin(/dont/)],
};

ContextReplacementPlugin

Context는 require('./locale/' + name + '.json')와 같은 import() 또는 require()의 동적 표현식을 의미합니다. 이러한 표현식을 만나면 webpack은 디렉터리(./locale/')와 정규 표현식(/^.*\.json$/)을 추론합니다. 컴파일 시점에 name을 알 수 없으므로 webpack은 모든 파일을 모듈로 번들에 포함합니다.

ContextReplacementPlugin을 사용하면 추론된 정보를 오버라이드 할 수 있습니다. 플러그인을 구성하는 방법에는 여러 가지가 있습니다.

Usage

new webpack.ContextReplacementPlugin(
  resourceRegExp: RegExp,
  newContentResource?: string,
  newContentRecursive?: boolean,
  newContentRegExp?: RegExp
)

리소스(디렉터리)가 resourceRegExp와 일치하면, 플러그인은 기본 리소스, 재귀 플래그 또는 생성된 정규식을 각각 newContentResource, newContentRecursive 또는 newContentRegExp로 바꿉니다. newContentResource가 상대적인 경우 이전 리소스를 기준으로 해결됩니다.

다음은 모듈 사용을 제한하는 작은 예제입니다.

new webpack.ContextReplacementPlugin(/moment[/\\]locale$/, /de|fr|hu/);

moment/locale 컨텍스트는 /de|fr|hu/와 일치하는 파일로 제한됩니다. 따라서 해당 locale만 포함됩니다(자세한 내용은 이 이슈를 참고하세요).

Content Callback

new webpack.ContextReplacementPlugin(
  resourceRegExp: RegExp,
  newContentCallback: (data) => void
);

newContentCallback 함수에는 ContextModuleFactory의 data 객체가 제공되며 제공된 객체의 request 속성을 덮어쓸 것으로 예상됩니다.

이 콜백을 사용하여 요청을 새 위치로 동적 리다이렉션할 수 있습니다.

new webpack.ContextReplacementPlugin(/^\.\/locale$/, (context) => {
  if (!/\/moment\//.test(context.context)) return;

  Object.assign(context, {
    regExp: /^\.\/\w+/,
    request: "../../locale", // 상대적으로 해결
  });
});

Other Options

newContentResource 및 newContentCreateContextMap 파라미터도 사용할 수 있습니다.

new webpack.ContextReplacementPlugin(
  resourceRegExp: RegExp,
  newContentResource: string,
  newContentCreateContextMap: object // 런타임-요청(userRequest)을 컴파일-시간-요청(request)으로 매핑
);

이 두 파라미터를 함께 사용하여 보다 대상화된 방식으로 요청을 리다이렉션할 수 있습니다. newContentCreateContextMap을 사용하면 런타임 요청을 매핑하여 객체 형태로 요청을 컴파일 할 수 있습니다.

new ContextReplacementPlugin(/selector/, "./folder", {
  "./request": "./request",
  "./other-request": "./new-request",
});

CopyPlugin

빌드 과정에서 파일과 디렉터리를 output.path로 복사합니다. 이 plugin은 output.copy의 기반이며, 해당 옵션을 설정하면 webpack이 자동으로 적용합니다. output.copy에서 제공하지 않는 concurrency 또는 stage 옵션이 필요할 때 plugin을 직접 사용하세요.

import webpack from "webpack";

new webpack.CopyPlugin(options);

Options

{
  patterns: (string | object)[], // 복사할 항목, output.copy 참고
  concurrency?: number, // 동시에 읽을 파일 수
  stage?: number, // 파일을 복사할 processAssets 단계
}

• patterns ((string | object)[]): 복사할 파일입니다. 패턴은 from과 context, filename, globOptions, info, preservePermissions, preserveTimestamps, to, transform으로 구성됩니다. 동일한 패턴을 사용하는 output.copy에서 모두 설명합니다.
• concurrency (number = 100): 동시에 읽을 수 있는 최대 파일 수입니다.
• stage (number = webpack.Compilation.PROCESS_ASSETS_STAGE_ADDITIONAL): 파일을 복사할 processAssets 단계입니다. 기본 단계에서는 복사된 파일도 다른 애셋과 마찬가지로 최소화되고 압축됩니다. 이후 단계를 지정하면 이러한 작업을 수행할 tap이 끝난 뒤 파일을 emit합니다.

Usage

import webpack from "webpack";

export default {
  // ...
  plugins: [
    new webpack.CopyPlugin({
      patterns: [
        "static",
        { from: "img", to: "images" },
        { from: "licenses/*.txt", to: "licenses" },
      ],
      concurrency: 50,
    }),
  ],
};

Keeping a file out of the minimizer

미리 빌드된 파일은 이미 최소화되어 있으므로 minimizer를 다시 실행하면 불필요하게 시간만 소요됩니다. asset info에 최소화된 파일이라고 표시하면 minimizer가 해당 파일을 건너뜁니다.

import webpack from "webpack";

export default {
  // ...
  plugins: [
    new webpack.CopyPlugin({
      patterns: [
        {
          from: "*.min.js",
          context: "vendor",
          to: "vendor",
          info: { minimized: true },
        },
      ],
    }),
  ],
};

Merging copied assets

하나의 소스 파일은 하나의 애셋이 되므로 여러 파일을 하나로 합치려면 복사된 결과물을 다시 처리해야 합니다. 이 작업은 어떤 plugin으로도 수행할 수 있습니다. 복사된 애셋의 asset info에는 copied: true가 포함되므로 다음과 같이 대상을 선별할 수 있습니다.

compilation.hooks.processAssets.tap(
  {
    name: "MergeCopiedAssetsPlugin",
    stage: webpack.Compilation.PROCESS_ASSETS_STAGE_DERIVED,
  },
  () => {
    const assets = compilation
      .getAssets()
      .filter((asset) => asset.info.copied && /^licenses\//.test(asset.name))
      .toSorted((a, b) => (a.name < b.name ? -1 : 1));
    if (assets.length === 0) return;

    const merged = assets
      .map((asset) => `/* ${asset.name} */\n${asset.source.source()}`)
      .join("\n");

    compilation.emitAsset(
      "THIRD_PARTY_LICENSES.txt",
      new webpack.sources.RawSource(merged),
      { copied: true },
    );
    for (const asset of assets) compilation.deleteAsset(asset.name);
  },
);

DefinePlugin

DefinePlugin을 사용하면 컴파일 타임에 구성할 수 있는 전역 상수를 만들 수 있습니다. 이는 개발 빌드와 프로덕션 빌드 간에 서로 다른 동작을 하고 싶을 때 유용합니다. 개발 빌드에서 로깅을 수행하지만, 프로덕션 빌드에서는 수행하지 않는 경우 전역 상수를 사용하여 로깅을 수행할지 여부를 결정할 수 있습니다. 이것이 DefinePlugin가 유용한 이유입니다. 이 플러그인을 설정하고 개발 및 프로덕션 빌드 환경을 잊어버리세요.

new webpack.DefinePlugin({
  // Definitions...
});

Usage

DefinePlugin에 전달된 각 키는 .로 결합 된 개별 또는 다중 식별자입니다.

• 값이 문자열이면 이는 코드 조각으로 사용됩니다.
• 값이 문자열이 아닌 경우 문자열화 됩니다(함수를 포함해서).
• 값이 객체라면 모든 키가 동일한 방식으로 정의됩니다.
• 키에 typeof 접두사를 붙이면 typeof 호출에 대해서만 정의됩니다.

값은 코드에 인라인 되어 중복 조건을 제거하기 위한 최소화 단계를 거치게 됩니다.

new webpack.DefinePlugin({
  PRODUCTION: JSON.stringify(true),
  VERSION: JSON.stringify("5fa3b9"),
  BROWSER_SUPPORTS_HTML5: true,
  TWO: "1+1",
  "typeof window": JSON.stringify("object"),
  "process.env.NODE_ENV": JSON.stringify(process.env.NODE_ENV),
});

console.log(`Running App version ${VERSION}`);
if (!BROWSER_SUPPORTS_HTML5) require("html5shiv");

if (!PRODUCTION) {
  console.log("Debug info");
}

if (PRODUCTION) {
  console.log("Production log");
}

최소화 단계 없이 webpack을 통과하면 다음과 같은 결과가 나타납니다.

if (!true) {
  console.log("Debug info");
}
if (true) {
  console.log("Production log");
}

그 후 최소화 단계를 거친 결과는 다음과 같습니다.

console.log("Production log");

Feature Flags

기능 플래그를 사용하여 프로덕션/개발 빌드 기능을 활성화/비활성화 할 수 있습니다.

new webpack.DefinePlugin({
  NICE_FEATURE: JSON.stringify(true),
  EXPERIMENTAL_FEATURE: JSON.stringify(false),
});

Service URLs

프로덕션/개발 빌드에서 서로 다른 서비스 URL을 사용할 수 있습니다.

new webpack.DefinePlugin({
  SERVICE_URL: JSON.stringify("https://dev.example.com"),
});

Runtime values via runtimeValue

(fn: (context: { module: NormalModule, key: string, version: string | undefined }) => CodeValuePrimitive, options?: true | string[] | RuntimeValueOptions) => RuntimeValue

파일에 의존하는 값으로 변수를 정의할 수 있으며 이러한 파일이 파일 시스템에서 변경 될 때 재평가 됩니다. 이는 감시된 파일이 변경될 때 webpack이 재빌드 됨을 의미합니다.

webpack.DefinePlugin.runtimeValue 함수에는 두 가지 인자가 있습니다.

• 첫 번째 인자는 위의 제너레이터 함수입니다. { module, key, version }을 받아 정의에 할당할 값을 반환합니다.
• 두 번째 인자는 감시할 파일 경로의 배열이거나 모듈을 캐시 할 수 없음으로 표시하는 true 플래그일 수 있습니다. 5.26.0 버전부터는 아래의 속성을 가진 객체 인자를 사용할 수 있습니다.
  • fileDependencies?: string[] 함수가 의존하는 파일 목록입니다.
  • contextDependencies?: string[] 함수가 의존하는 디렉터리 목록입니다.
  • missingDependencies?: string[] 함수가 의존하는 존재하지 않는 파일 목록입니다.
  • buildDependencies?: string[] 함수가 의존하는 빌드 디펜던시 목록입니다.
  • version?: string | () => string 함수의 버전입니다.

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

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

const fileDep = path.resolve(__dirname, "sample.txt");

new webpack.DefinePlugin({
  BUILT_AT: webpack.DefinePlugin.runtimeValue(Date.now, {
    fileDependencies: [fileDep],
  }),
});

BUILT_AT의 값은 'sample.txt'가 파일 시스템에서 마지막으로 업데이트된 시간입니다. (예: 1597953013291)

DiagnosticsWebpackPlugin

This plugin only supports webpack >= 5.106.0 and Node.js >= 22.12.0.

This plugin runs linters, type checkers and other diagnostic tools over your sources during the webpack build and reports what they find as webpack errors and warnings.

It replaces eslint-webpack-plugin and stylelint-webpack-plugin: one plugin, one place to configure how problems are reported, and one pass over your project. Today it runs ESLint, Stylelint, oxlint, Biome and TypeScript; more linters and diagnostic tools are meant to be added the same way.

Getting Started

To begin, you'll need to install diagnostics-webpack-plugin:

npm install diagnostics-webpack-plugin --save-dev

or

yarn add -D diagnostics-webpack-plugin

or

pnpm add -D diagnostics-webpack-plugin

[!NOTE]

Install the tools you want to run as well — the plugin only requires the ones you enable. It supports eslint >= 9, stylelint >= 17, oxlint >= 1, @biomejs/biome >= 2 and typescript >= 5:

npm install eslint stylelint oxlint @biomejs/biome typescript --save-dev

Then add the plugin to your webpack configuration and enable a check for each language you want inspected:

import DiagnosticsPlugin from "diagnostics-webpack-plugin";

export default {
  // ...
  plugins: [
    new DiagnosticsPlugin({
      checks: [
        { use: "eslint", extensions: ["js", "mjs"] },
        { use: "stylelint", extensions: ["css", "scss"] },
      ],
    }),
  ],
  // ...
};

The package ships an ECMAScript build next to a CommonJS one, so a CommonJS configuration works just as well:

const DiagnosticsPlugin = require("diagnostics-webpack-plugin");

Options

The plugin options have three layers:

The options are checked against their schema from webpack's own validate hook, so a mistake is reported when webpack validates the rest of your configuration, and validate: false turns the check off along with webpack's.

Every check to run is an entry in checks, named by its use. The list may name the same tool more than once, so one instance can inspect two file sets under different configurations.

Every option

Anything else written in a checks entry is handed to the tool itself, so its own Node.js API options go next to these.

new DiagnosticsPlugin({
  // Plugin options
  context: "src",
  // Shared options, every check uses them unless it says otherwise
  reportAs: "warning", // report every check's results as warnings
  exclude: ["node_modules", "vendor"],
  // The checks to run, each with the options only it understands
  checks: [
    { use: "eslint", extensions: ["js", "ts"], fix: true },
    { use: "stylelint", extensions: ["css", "scss"], threads: true },
  ],
});

Plugin options

checks

• Type:

type checks = (string | ({ use: string | CheckAdapter } & Options))[];

• Default: none — this is the one option the plugin requires

The checks to run. An entry is the name of a built-in check, or an object naming it under use next to the options it takes, so these two are the same thing:

new DiagnosticsPlugin({ checks: ["eslint", { use: "eslint" }] });

Naming the same tool twice runs it twice, which is how one build checks two file sets under two configurations:

new DiagnosticsPlugin({
  checks: [
    { use: "eslint", files: "src", fix: true },
    { use: "eslint", files: "scripts", reportAs: "warning" },
  ],
});

use also takes an adapter of your own rather than a built-in name — see Adding a check.

context

• Type:

type context = string;

• Default: compiler.context

Base directory for linting. Every relative files and exclude pattern is resolved against it.

lintOnStart

• Type:

type lintOnStart = boolean;

• Default: true

Whether the first compilation lints every file it covers. Leave it alone and a build lints everything while a watch run lints everything once and then only what webpack rebuilds.

Set it to false to start a watch run quiet: nothing is linted until you touch a file, and only the modules webpack rebuilds are reported. A build is nothing but a first compilation, so it lints either way — the option cannot silence one.

Running the checks in one mode only

There is no option for this and none is needed: plugins ignores a falsy entry, so && decides whether the plugin is there at all. A configuration function is handed the --env values, and webpack-cli states the mode in them:

import DiagnosticsPlugin from "diagnostics-webpack-plugin";
import { defineConfig } from "webpack";

export default defineConfig((env) => ({
  plugins: [
    // Both values are read because each command sets only its own: `serve` sets
    // `WEBPACK_SERVE` and `--watch` sets `WEBPACK_WATCH`, so asking for one of
    // them misses the other way of watching. Read `WEBPACK_BUILD` instead to
    // check a build that runs once and leave a watch run alone.
    (env.WEBPACK_SERVE || env.WEBPACK_WATCH) &&
      new DiagnosticsPlugin({ checks: ["eslint", "stylelint"] }),
  ],
}));

This is worth doing when something else already lints the same files — a CI job running eslint ., or an editor — and the release build need not pay for it twice.

Two configurations at once

A client and a server configuration lint the same sources twice. Where two compilers run a check configured the same way over the same files — the whole of it for a check reading from the file system, whatever they both built for one reading the module graph — the second joins the run the first is making rather than starting its own, and both compilations report what it finds and watch what it read.

Over three hundred files with the typescript check, two compilers build one program rather than two: 1.52 s rather than 1.79 s, and 248 MB rather than 298 MB. What a compiler checks alone it still checks alone, and a check configured differently in the second configuration runs on its own.

Shared options

These can be set at the top level, where they apply to every check, or inside one check, where they apply to that check alone.

cache

• Type:

type cache = boolean;

• Default: true

The cache is enabled by default to decrease execution time.

It is turned off for an ESLint check doing typed linting: a cache keyed on one file's own contents cannot answer for a rule that read another.

cacheLocation

• Type:

type cacheLocation = string;

• Default: node_modules/.cache/diagnostics-webpack-plugin/.<tool>cache

Specify the path to the cache location. Can be a file or a directory.

files

• Type:

type files = string | string[];

• Default: options.context

Specify directories, files, or globs. Must be relative to options.context. Directories are traversed recursively looking for files matching options.extensions. File and glob patterns ignore options.extensions.

Naming them says what to check, so every file they match is checked whether or not webpack built it — a module nothing imports yet, or one reached through a loader webpack resolves differently, is checked all the same. Leave it unset and a check reads whatever it reads by itself: ESLint the modules webpack built, Stylelint a walk of the context.

In a watch run the folder a check takes its files from is watched, so a file you add there is checked without anything else having to change — and for the typescript check, so is every folder the tsconfig.json include covers. A folder is only watched when the whole of it can be: webpack rebuilds on a change anywhere under one, so a folder holding what the build writes (output.path) or what the check itself leaves out (exclude, node_modules by default) is left alone rather than turning every write into a rebuild. Pointing files at your sources rather than leaving it at the project root is what makes it watchable.

extensions

• Type:

type extensions = string | string[];

• Default: 'js' for ESLint, ['css', 'scss', 'sass'] for Stylelint

Specify file extensions that should be checked.

exclude

• Type:

type exclude = string | string[];

• Default: 'node_modules', plus output.path for Stylelint

Specify the files/directories to exclude. Must be relative to options.context.

threads

• Type:

type threads = boolean | number | "auto";

• Default: "auto"

How many threads a check spreads its work over. "auto" takes one fewer than the machine has, leaving webpack the thread it builds on; a number asks for that many; false, 0 or 1 keeps the work on webpack's own thread.

A check that threads its own work is asked to, and one that cannot is run in a pool of workers — so the option means the same thing whatever is being checked, and a check added later gets it for nothing. ESLint threads its own work from 9.34.0 under flat config; Stylelint threads none of its own, so it is pooled. TypeScript reads a program whole rather than a file at a time, so it is run on one worker: what a thread buys it is webpack's own thread back.

Prefer "auto" over a count. A check sizes "auto" against the machine, where a fixed number can end up competing with webpack for the same cores: over three hundred modules on four of them, "auto" took about a fifth off the build while asking for three was no better than asking for none. A count above what the machine has is held to it, since asking for sixteen threads on four cores took twice as long as asking for none — the ceiling cannot save a number written against the tool itself, such as ESLint's concurrency, which is passed through as written.

Anything written against the tool itself wins — ESLint's own concurrency, say — and a check configured with a function, such as a formatter written in the configuration, is run on webpack's thread, because a function cannot be handed to a worker.

resourceQueryExclude

• Type:

type resourceQueryExclude = RegExp | RegExp[] | string | string[];

• Default: []

Specify the resource query to exclude. A string is read as the source of a regular expression, so "raw" and /raw/ mean the same thing. Only affects checks that read the module graph, such as ESLint.

fix

• Type:

type fix = boolean;

• Default: false

Will enable the autofix feature of the tool.

Be careful: this option will modify source files.

formatter

• Type:

type formatter = string | ((results: LintResult[]) => string);

• Default: the tool's own default formatter

Accepts the name of a formatter the tool ships, or a function that receives its results and returns the output as a string.

See the ESLint formatters and the Stylelint formatter option.

Errors and warnings

Every check reports its errors as webpack errors and its warnings as webpack warnings, which is what fails the build. reportAs overrides that.

reportAs

• Type:

type reportAs = Severity | { errors?: Severity; warnings?: Severity };
type Severity = "error" | "warning" | "log" | false;

• Default: unset — each result stays at the severity the check gave it

What a check reports its results as. One value covers its errors and its warnings alike; an object sets them apart, and a severity the object leaves out keeps its own:

new DiagnosticsPlugin({
  reportAs: { warnings: false }, // the errors alone
  checks: [{ use: "eslint" }],
});

"log" is for a check nobody should be stopped by yet. Its results reach webpack's log — the terminal, and stats.logging — rather than compilation.errors or compilation.warnings, so the build carries neither, stats.hasWarnings() stays false and a dev server overlays nothing. An outputReport is written either way.

new DiagnosticsPlugin({
  // the whole project is linted, and only the new check is advisory
  checks: [{ use: "eslint" }, { use: "typescript", reportAs: "log" }],
});

A check nothing can be reported from is one a watch rebuild does not wait for: every reportAs that leaves both errors and warnings off the compilation — "log", false, or an object spelling both out — with no outputReport to write. The first build still waits, since it is what tells the watcher which files the check reads. From the rebuild on, the check is run once the build is over rather than beside it, and what it finds is printed through webpack's infrastructure log rather than through stats.logging.

The work is moved out of the rebuild rather than off the machine: an edit arriving while such a check is still running waits for the rest of it, since a check holds the thread the build runs on. A report a newer rebuild has already overtaken is dropped, and a check never has two of its runs going at once — the next starts when the last has reported.

ignoreDiagnostics

• Type:

type ignoreDiagnostics =
  IgnoreOne | IgnoreOne[] | ((message: Message) => boolean);

type IgnoreOne = number | string | IgnoreMatch;

interface IgnoreMatch {
  file?: string | undefined;
  code?: string | undefined;
  severity?: "error" | "warning" | undefined;
}

interface Message {
  file?: string | undefined;
  code?: string | undefined;
  severity: "error" | "warning";
  text: string;
}

• Default: unset

What not to report. A linter's rule can be turned off in its own configuration and a TypeScript diagnostic cannot, so this is where one thing a check found is left out whichever check found it — for adopting a check on a project that is not clean yet, without turning the check off altogether.

new DiagnosticsPlugin({
  checks: [
    // TS2307 is `Cannot find module`, TS7016 an untyped dependency
    { use: "typescript", ignoreDiagnostics: [2307, 7016] },
    // a rule that has not been dealt with in one folder yet
    {
      use: "eslint",
      ignoreDiagnostics: { code: "no-unused-vars", file: "src/legacy/**" },
    },
  ],
});

A file is a glob matched against the path relative to context, as exclude is. Something a check reported of no file in particular — a configuration it could not read — is not a file's to leave out, so a match naming one keeps it.

What is left out is left out of everything the check reports, an outputReport included, and of the counts a formatter prints. A check shipped outside this package answers for its own results, so it reads this option once it says how (see Adding a check).

outputReport

• Type:

type outputReport =
  | boolean
  | {
      filePath?: string | undefined;
      formatter?: (string | ((results: LintResult[]) => string)) | undefined;
    };

• Default: false

Write the results to a file, for example a checkstyle xml file for use for reporting on Jenkins CI.

• filePath: path to the output report file, relative to output.path unless absolute.
• formatter: a different formatter for the output file; the default/configured formatter is used when none is passed in.

Set at the top level, every check appends its report to the same file. Set it inside a checks entry to give that check a file of its own.

new DiagnosticsPlugin({
  checks: [
    {
      use: "eslint",
      outputReport: { filePath: "eslint.json", formatter: "json" },
    },
    {
      use: "stylelint",
      outputReport: { filePath: "stylelint.json", formatter: "json" },
    },
  ],
});

ESLint

Run with { use: "eslint" }. It lints the files webpack builds, so only the modules that end up in the bundle are checked.

Alongside the shared options you can pass any ESLint Node.js API option — they are handed to the ESLint class as they are.

threads reaches ESLint as its own concurrency from 9.34.0 under flat config, and an older ESLint or an eslintrc one is pooled instead. Write concurrency yourself and that is what ESLint is given, whatever threads says. Note that webpack spells this idea parallelism, and uses the word concurrency for something else again — bounded work on one thread.

A rebuild lints only the files webpack rebuilt and reports the rest from the previous run, so lintOnStart is only worth setting to start a watch run quiet.

Typed linting is the exception, and it is read from your configuration rather than asked of you. Where parserOptions.project or parserOptions.projectService is set, what a rule reports of one file can turn on another — a type it imported, a declaration file something regenerated — so a file that did not itself change is not one whose last result still holds. A rebuild then lints every file the check covers, and ESLint's own cache is turned off for it, since that cache is keyed on each file's own contents and would answer for a type it never read.

configType

• Type:

type configType = "flat" | "eslintrc";

• Default: flat

Specify the type of configuration to use with ESLint.

• flat is the current standard configuration format.
• eslintrc is the legacy configuration format and has been officially deprecated.

The new configuration format is explained in its own documentation.

eslintrc needs an ESLint that still reads one: ESLint 9 does, ESLint 10 removed it, and the option stays for as long as this plugin supports 9. The check loads ESLint the same way wherever it runs it, in the build's own thread and in a worker of a pool alike, and the ESLint 9 job in CI checks both.

eslintPath

• Type:

type eslintPath = string;

• Default: eslint

Path to the eslint instance that will be used for linting.

If the eslintPath is a folder like the official ESLint, or you specify a formatter option, you don't have to install eslint.

Suppressions

Bulk suppressions are supported: enable ESLint's own applySuppressions, and point suppressionsLocation at the file if it is not the default eslint-suppressions.json.

new DiagnosticsPlugin({
  checks: [{ use: "eslint", applySuppressions: true }],
});

[!IMPORTANT]

ESLint resolves the suppressions file, and every path recorded inside it, against its own cwd — not against the plugin's context. Where the two differ, pass cwd to the check as well:

Copy

new DiagnosticsPlugin({
  context: "src",
  checks: [
    { use: "eslint", applySuppressions: true, cwd: import.meta.dirname },
  ],
});

Suppressions need ESLint 9.24 or later. ESLint 10 takes both options itself; below that they reach its CLI alone, so the plugin applies the suppressions after linting instead — the same file, the same paths, the same result.

Stylelint

Run with { use: "stylelint" }, and requires stylelint >= 17. It lints every file matching files and extensions on disk, whether or not webpack imported it, so a stylesheet nothing imports yet is still checked.

Alongside the shared options you can pass any Stylelint option — they are handed to stylelint.lint() as they are.

stylelintPath

• Type:

type stylelintPath = string;

• Default: stylelint

Path to the stylelint instance that will be used for linting.

oxlint

Run with { use: "oxlint" }, and requires oxlint >= 1. It lints the files webpack builds, as the ESLint check does, and reads whatever .oxlintrc.json oxlint finds for itself.

new DiagnosticsPlugin({ checks: ["eslint", "oxlint"] });

oxlint is a binary behind a Node entry rather than a library, so this check runs it and reads the JSON it answers with. Two things follow. Its severities are oxlint's own — a rule set to "error" in .oxlintrc.json is reported as a webpack error and one set to "warn" as a warning, and reportAs moves them from there as it does for every check. And the options this check does not name are not guessed at: write them as args, the flags oxlint itself documents.

oxlintPath

• Type:

type oxlintPath = string;

• Default: oxlint

Path to the oxlint instance that will be used for linting.

configFile

• Type:

type configFile = string;

• Default: unset, leaving oxlint to find its own

Path to the .oxlintrc.json to lint with.

args

• Type:

type args = string[];

• Default: []

Arguments passed to oxlint as they are, for the flags this check does not name — ["--deny", "correctness"], say. Not --format: the check asks for JSON and formats the results itself, and oxlint declines being asked twice.

Biome

Run with { use: "biome" }, and requires @biomejs/biome >= 2. It checks the files webpack builds and reads whatever biome.json Biome finds for itself, reporting at Biome's own severities.

new DiagnosticsPlugin({ checks: ["biome"] });

Like the oxlint check this runs a binary and reads the JSON it answers with, which Biome calls an experimental reporter — a release of its own may move the shape, and it is the only reporter carrying the severities this check needs.

biomePath

• Type:

type biomePath = string;

• Default: @biomejs/biome

Path to the @biomejs/biome instance that will be used for checking.

command

• Type:

type command = "lint" | "check";

• Default: "lint"

Which of Biome's commands to run. "lint" runs the linter; "check" adds its formatting and assist diagnostics, so a badly formatted file is reported as well as one breaking a rule.

configFile

• Type:

type configFile = string;

• Default: unset, leaving Biome to find its own

Path to the biome.json to check with.

args

• Type:

type args = string[];

• Default: []

Arguments passed to Biome as they are, for the flags this check does not name. Not --reporter: the check asks for JSON and formats the results itself.

TypeScript

Run with { use: "typescript" }, and requires typescript >= 5. It type checks the program a tsconfig.json describes, so every file that config includes is checked whether or not webpack built it, and a type error in a module nothing imports yet is still reported. Emit is forced off: webpack writes the output.

new DiagnosticsPlugin({
  checks: [{ use: "typescript", configFile: "tsconfig.build.json" }],
});

Project references are read rather than built unless build says otherwise, which is what a tsconfig.json listing only references needs.

Two things differ from the linters. A diagnostic belongs to the program rather than to one file, so there is nothing to report a single file from. And extensions only decides which files make the check run at all; what is checked is whatever the config file includes.

A program is read whole, so threads buys it webpack's own thread back rather than a share of the work: the check runs on one worker while webpack builds, and is read where it is reported. Over a three-hundred-file solution beside three hundred modules that took the build from 2149 ms to 1920 ms and the module graph from 2004 ms to 385 ms, and an edit-to-report in watch from 259 ms to 203 ms. A small project pays the thread's start without much to hide behind it; threads: false keeps the work where webpack is.

While webpack watches, the program is kept and handed to the build after it, so a rebuild type checks what the change reaches rather than the project over again — about 30 ms rather than 300 over three hundred files, for the memory the program holds on to (some 50 MB there). A change to the config file, or to the compiler options given here, starts a new one.

Alongside the shared options you can pass any compiler option — they override what the config file sets, as --strict would on the command line.

typescriptPath

• Type:

type typescriptPath = string;

• Default: typescript

Path to the typescript instance that will be used for checking.

configFile

• Type:

type configFile = string;

• Default: the nearest tsconfig.json at or above context

Path to the tsconfig.json that describes the program.

compilerOptions

• Type:

type compilerOptions = object;

• Default: unset

Compiler options overriding the ones the config file sets. The same as writing them at the top level of the check, and useful when a name collides with one of the plugin's own.

build

• Type:

type build = boolean;

• Default: false

Build the projects the config file references before reporting, the way tsc -b does. A tsconfig.json that only lists references describes an empty program of its own, so without this a solution reports nothing at all; with it, every project in the graph is checked in the order its references say.

new DiagnosticsPlugin({
  checks: [{ use: "typescript", build: true }],
});

A reference is read through the declarations the referenced project publishes, so building one is how the next is checked at all — the build therefore writes each project's .d.ts and its .tsbuildinfo, and nothing else. The JavaScript stays webpack's to write: a later tsc -b of your own still emits it. mode says so in full, and can say otherwise.

The cost is a tsc -b pass rather than the kept program the check uses otherwise. Over five projects and 205 files: 573 ms with nothing built yet, 4–8 ms when the solution is up to date, 258 ms after one file changed, and around 200 ms on every rebuild for as long as an error stands, since a project that fails is never up to date. Pair it with reportAs: "log" if you would rather a watch rebuild did not wait for that.

mode

• Type:

type mode = "readonly" | "write-tsbuildinfo" | "write-dts" | "write-references";

• Default: "write-dts" under build, "readonly" otherwise

What the check writes as well as reports. A check reports, so by default a program writes nothing at all and a solution writes only what the next project has to read.

new DiagnosticsPlugin({
  checks: [{ use: "typescript", build: true, mode: "write-references" }],
});

readonly under build is not the compiler's noEmit, which tsc -b refuses with TS6310: the build runs and its output is kept where only that build can read it, so a project still finds the declarations of the one it references while your working tree is left alone.

diagnosticOptions

• Type:

interface diagnosticOptions {
  syntactic?: boolean | undefined;
  semantic?: boolean | undefined;
  declaration?: boolean | undefined;
  global?: boolean | undefined;
}

• Default: every kind reported

Which kinds of diagnostic to report. Turning one off asks TypeScript for less rather than dropping what it answered, so it is also the one filter that saves the work — semantic: false is what makes a check that only wants syntax errors cheap.

new DiagnosticsPlugin({
  // webpack's own parser reports a syntax error in a file it builds
  checks: [{ use: "typescript", diagnosticOptions: { syntactic: false } }],
});

What the tsconfig.json itself is wrong about is reported whatever is turned off here: with the config file misread, nothing below it would be answering the right question. build reports the whole of what it finds either way, since a solution is built rather than asked kind by kind.

fork-ts-checker-webpack-plugin spells this option the same way, with semantic alone on by default.

Adding a check

A use may also be an adapter of its own rather than a built-in name, so a check can ship as its own package without an entry in this one:

new DiagnosticsPlugin({
  checks: [
    { use: require("diagnostics-webpack-plugin-typescript"), strict: true },
  ],
});

Such an adapter is an object with a name, and a create returning the five functions the plugin drives it through — what to lint, what came back, which results are errors and which warnings, how to format them, and what to release afterwards. It splits its results by their own severity and nothing else; reportAs is applied to what it returns:

module.exports = {
  name: "made-up",
  // "modules" lints the files webpack built, "glob" every file matching `files`
  filesSource: "glob",
  // Merged under the options the user passes, and under the shared options
  defaults: { extensions: ["ts"] },
  async create({ key, options, compilation }) {
    return {
      lintFiles: async (files) => runTheTool(files),
      getResults: async (results) => results,
      splitResults: (results) => ({ errors: results, warnings: [] }),
      getFormatter: async (formatter) => async (results) => format(results),
      cleanup: async () => {},
    };
  },
};

label, filesSource, defaults, defaultExclude and schema are optional; the plugin fills in the defaults of a module-scanning check that excludes node_modules.

Migrating

Both plugins become one, and every option they had is still here. What changed is where an option is written and how the four that decided severity are spelled.

Where an option goes. context, lintOnStart and checks are the plugin's own and stay at the top level. Everything else is shared: write it at the top level to cover every check, or inside a checks entry to cover that one. configType, eslintPath and stylelintPath belong to a single check and go in its entry.

Severity is one option. emitError, emitWarning, failOnError, failOnWarning and quiet are reportAs, because reporting a result as a webpack error is what fails the build:

The build is no longer aborted from inside the plugin. A result reported as a webpack error fails the build the way every other webpack error does — stats.hasErrors() is true and the CLI exits non-zero — and the assets are still written. Nothing about severity depends on mode any more.

Requirements. Node >= 22.12, webpack >= 5.106, and ESLint 9 or 10 / Stylelint 17 for whichever checks you run.

From eslint-webpack-plugin

-const ESLintPlugin = require("eslint-webpack-plugin");
+const DiagnosticsPlugin = require("diagnostics-webpack-plugin");

 module.exports = {
   plugins: [
-    new ESLintPlugin({ extensions: ["js"], fix: true }),
+    new DiagnosticsPlugin({
+      checks: [{ use: "eslint", extensions: ["js"], fix: true }],
+    }),
   ],
 };

Every option eslint-webpack-plugin accepted, and where it is now:

Any other option is passed to ESLint itself, as before.

From stylelint-webpack-plugin

-const StylelintPlugin = require("stylelint-webpack-plugin");
+const DiagnosticsPlugin = require("diagnostics-webpack-plugin");

 module.exports = {
   plugins: [
-    new StylelintPlugin({ extensions: ["css"], threads: true }),
+    new DiagnosticsPlugin({
+      checks: [{ use: "stylelint", extensions: ["css"], threads: true }],
+    }),
   ],
 };

Every option stylelint-webpack-plugin accepted, and where it is now:

Any other option is passed to Stylelint itself, as before. Two more things changed for Stylelint alone:

• Stylelint 17 or later is required. stylelint-webpack-plugin accepted 13 through 17; the merged plugin drops the older majors rather than carrying their compatibility branches forward. Stylelint 17 itself needs Node >= 20.19.
• Errors and warnings are no longer swapped. failOnError: false used to report errors as webpack warnings, and failOnWarning: true to report warnings as webpack errors. Each result now keeps its own severity unless reportAs says otherwise — which is what those two spellings in the table above do, explicitly.

fix is a documented option now rather than one passed through to Stylelint unnamed. resourceQueryExclude is shared but has no effect here: it reads the query of a module webpack built, and Stylelint is given the files matching files instead.

Running both

The two plugins become one instance, and options they had in common are written once:

 module.exports = {
   plugins: [
-    new ESLintPlugin({ context: "src", failOnError: true, extensions: ["js"] }),
-    new StylelintPlugin({ context: "src", failOnError: true, extensions: ["css"] }),
+    new DiagnosticsPlugin({
+      context: "src",
+      checks: [
+        { use: "eslint", extensions: ["js"] },
+        { use: "stylelint", extensions: ["css"] },
+      ],
+    }),
   ],
 };

From fork-ts-checker-webpack-plugin

The typescript check does what that plugin does — type check the program a tsconfig.json describes, rather than the files webpack happens to build — and is written as one entry in checks:

-const ForkTsCheckerWebpackPlugin = require("fork-ts-checker-webpack-plugin");
+const DiagnosticsPlugin = require("diagnostics-webpack-plugin");

 module.exports = {
   plugins: [
-    new ForkTsCheckerWebpackPlugin({
-      typescript: { configFile: "tsconfig.build.json", build: true },
-    }),
+    new DiagnosticsPlugin({
+      checks: [
+        { use: "typescript", configFile: "tsconfig.build.json", build: true },
+      ],
+    }),
   ],
 };

The check runs on a worker thread rather than in a process of its own. That plugin forks one, which is why it has a memoryLimit and a profile; a thread shares the build's heap and its copy of TypeScript, so neither is needed here. The program is kept between rebuilds either way. What that costs and saves is under the TypeScript check.

Over a generated 300-file project, three runs of each:

The time is the same within the run-to-run spread; the memory is not, and that is the thread rather than anything clever.

It is a drop-in, and was checked as one against a project neither of us wrote — the fork-ts-checker-webpack-plugin example that ts-loader ships, which is React and TSX through ts-loader. Swapping the plugin for { use: "typescript" } and nothing else reported the same TS2322 at the same line and column. Three things to expect while doing it:

• webpack must be 5.106 or newer, which is what the plugin requires at all.
• npm refuses to install alongside ESLint 8. The eslint peer here is optional but ranged ^9 || ^10, and npm resolves an optional peer it can see, so a project pinned to 8 needs its ESLint updated — or --legacy-peer-deps — even when no ESLint check is configured.
• fork-ts-checker-notifier-webpack-plugin has nothing to listen to. It taps that plugin's own hooks, so it goes when that plugin does.

Running it next to a linter is one plugin rather than two, with one place to say how what they find is reported:

new DiagnosticsPlugin({
  checks: [{ use: "eslint" }, { use: "typescript" }],
});

Changelog

Changelog

Contributing

We welcome all contributions!

If you're new here, please take a moment to review our contributing guidelines.

CONTRIBUTING

License

MIT

DllPlugin

DllPlugin과 DllReferencePlugin은 빌드 시간 성능을 크게 향상시키는 방식으로 번들을 분할하는 수단을 제공합니다. "DLL"이라는 용어는 원래 Microsoft에서 도입한 동적 링크 라이브러리를 나타냅니다.

DllPlugin

이 플러그인은 dll 전용 번들을 생성하기 위해 단독으로 별도의 webpack 설정에서 사용됩니다. 의존성을 매핑하기 위해 DllReferencePlugin에서 사용하는 manifest.json파일을 생성합니다.

• context (선택): 매니페스트 파일의 요청 컨텍스트 (기본값은 webpack 컨텍스트)
• format (boolean = false): true인 경우 매니페스트 json 파일(출력)이 형식화됩니다.
• name: 노출된 dll 함수의 이름 (TemplatePaths: [fullhash], [chunkhash], [contenthash], & [name] )
• path: 매니페스트 json 파일의 절대 경로 (출력)
• entryOnly (boolean = true): true인 경우 엔트리 포인트만 노출됩니다.
• type: dll 번들의 유형

new webpack.DllPlugin(options);

주어진 경로에 기록되는 manifest.json을 생성합니다. 여기에는 require와 import 요청에서 모듈 id로의 매핑이 포함됩니다. 이는 DllReferencePlugin 에서 사용됩니다.

이 플러그인을 output.library옵션과 결합하여 dll 함수를 노출(전역 범위로 확대)합니다.

DllReferencePlugin

이 플러그인은 기본 webpack 설정에서 사용되며, 사전 빌드된 의존성을 require 하기 위해 dll 전용 번들을 참조합니다.

• context: 매니페스트(또는 콘텐츠 프로퍼티)에 있는 요청의 (절대 경로) 컨텍스트
• extensions: dll 번들의 모듈을 해결하는데 사용되는 확장입니다(‘유효범위’를 사용할 때만 사용).
• manifest : content 및 name을 포함하는 객체 또는 컴파일 시 로드될 JSON 매니페스트의 절대 경로에 대한 문자열
• content (선택): 요청에서 모듈 id 로의 매핑(기본값은 manifest.content)
• name (선택): dll이 노출되는 식별자(기본값은 manifest.name)(externals 참조)
• scope (선택): dll의 콘텐츠에 접근하는데 사용되는 접두사
• sourceType (선택): dll이 노출되는 방법(libraryTarget)

new webpack.DllReferencePlugin(options);

dll 매니페스트 파일을 참조하여 의존성 이름을 모듈 id에 매핑한 다음, 내부 __webpack_require__함수를 사용하여 필요에 따라 요청합니다.

Modes

이 플러그인은 scoped 와 mapped 두 가지 모드에서 사용할 수 있습니다.

Scoped Mode

dll의 콘텐츠는 모듈 접두사 아래에서 접근 가능합니다. 즉, scope = 'xyz'로 dll의 파일 abc 는 require('xyz/abc')를 통해 접근할 수 있습니다.

Mapped Mode

dll의 콘텐츠는 현재 디렉터리에 매핑됩니다. 필요한 파일이 dll의 파일과 확인 후 일치하는 경우, dll의 파일이 대신 사용됩니다.

이 과정은 DLL 번들 내의 모든 파일을 해석한 후에 발생하므로, DLL 번들을 사용하는 쪽에서도 동일한 경로를 사용할 수 있어야 합니다. 예를 들어, DLL에 lodash와 abc 파일이 포함되어 있다면, 메인 번들에 해당 파일들을 포함시키는 대신 DLL 자체에서 import _ from "lodash"/require('lodash')와 import abs from "./abc"/require('./abc')를 사용하게 됩니다.

Usage

webpack.vendor.config.js

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

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

new webpack.DllPlugin({
  context: import.meta.dirname,
  name: "[name]_[fullhash]",
  path: path.join(__dirname, "manifest.json"),
});

webpack.app.config.js

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

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

new webpack.DllReferencePlugin({
  context: __dirname,
  manifest: path.join(__dirname, "manifest.json"),
  scope: "xyz",
  sourceType: "commonjs2",
});

Examples

Vendor 와 User

두 개의 개별 예제 폴더로, 유효범위와 컨텍스트를 보여줍니다.

References

Source

• DllPlugin source
• DllReferencePlugin source
• DllEntryPlugin source
• DllModuleFactory source
• ManifestPlugin source

Tests

• DllPlugin creation test
• DllPlugin without scope test
• DllReferencePlugin use Dll test

EnvironmentPlugin

EnvironmentPlugin을 사용해 process.env 키에 DefinePlugin을 간단히 적용할 수 있습니다.

Usage

EnvironmentPlugin은 키로 구성된 배열 혹은 키에 기본값이 매핑된 객체를 받습니다.

new webpack.EnvironmentPlugin(["NODE_ENV", "DEBUG"]);

이는 다음과 같은 DefinePlugin 적용과 동일합니다.

new webpack.DefinePlugin({
  "process.env.NODE_ENV": JSON.stringify(process.env.NODE_ENV),
  "process.env.DEBUG": JSON.stringify(process.env.DEBUG),
  // since webpack 5.103.0
  "import.meta.env.NODE_ENV": JSON.stringify(process.env.NODE_ENV),
  "import.meta.env.DEBUG": JSON.stringify(process.env.DEBUG),
});

Usage with default values

또는, EnvironmentPlugin은 키에 기본값을 매핑한 객체를 지원합니다. 키가 process.env에 정의되지 않은 경우에는 기본값을 사용합니다.

new webpack.EnvironmentPlugin({
  NODE_ENV: "development", // process.env.NODE_ENV가 정의되지 않은 경우 'development'를 사용하세요.
  DEBUG: false,
});

Example:

지금까지 구성해온 EnvironmentPlugin 설정을 테스트 파일 entry.js에 적용했을 때 어떻게 동작하는지 알아봅시다.

if (process.env.NODE_ENV === "production") {
  console.log("Welcome to production");
}
if (process.env.DEBUG) {
  console.log("Debugging output");
}

빌드하기 위해 터미널에서 NODE_ENV=production webpack을 실행했을 때 entry.js는 다음과 같습니다.

if ("production" === "production") {
  // <-- NODE_ENV의 'production'이 사용됩니다.
  console.log("Welcome to production");
}
if (false) {
  // <-- 기본값이 사용됩니다.
  console.log("Debugging output");
}

DEBUG=false webpack을 실행하면 다음과 같습니다.

if ("development" === "production") {
  // <-- 기본값이 사용됩니다.
  console.log("Welcome to production");
}
if ("false") {
  // <-- DEBUG의 'false'가 사용됩니다.
  console.log("Debugging output");
}

Use Case: Git Version

다음과 같은 EnvironmentPlugin 설정은 저장소의 마지막 커밋에 따른 process.env.GIT_VERSION (예시 "v5.4.0-2-g25139f57f")과 process.env.GIT_AUTHOR_DATE (예시 "2020-11-04T12:25:16+01:00")를 제공합니다.

import childProcess from "node:child_process";

function git(command) {
  return childProcess.execSync(`git ${command}`, { encoding: "utf8" }).trim();
}

new webpack.EnvironmentPlugin({
  GIT_VERSION: git("describe --always"),
  GIT_AUTHOR_DATE: git("log -1 --format=%aI"),
});

DotenvPlugin

써드 파티 DotenvPlugin (dotenv-webpack)을 사용해 dotenv 변수를 사용할 수 있습니다.

// .env
DB_HOST=127.0.0.1
DB_PASS=foobar
S3_API=mysecretkey

new Dotenv({
  path: "./.env", // env 파일 경로 (기본값)
  safe: true, // .env.example 로드 (기본값은 dotenv-safe를 사용하지 않는 "false")
});

EvalSourceMapDevToolPlugin

EvalSourceMapDevToolPlugin을 사용하면 소스맵 생성을 보다 세밀하게 제어할 수 있습니다. 또한 devtool 설정 옵션의 특정한 세팅에 의해 자동으로 활성화됩니다.

new webpack.EvalSourceMapDevToolPlugin(options);

이 플러그인은 모든 모듈을 소스맵이 데이터 URL로 추가된 eval() 호출로 감싸며, .map 파일은 방출되지 않습니다. SourceMapDevToolPlugin과 동일한 옵션 객체를 허용하지만, 별도의 소스맵 파일을 설명하는 옵션인 filename, fileContext, publicPath는 여기서는 해당 없으므로 무시되며, 함수 값의 append도 마찬가지입니다.

Options

다음과 같은 옵션이 지원됩니다.

type Matcher =
  | string
  | RegExp
  | ((name: string) => boolean)
  | (string | RegExp | ((name: string) => boolean))[];

string은 접두사로 일치하고, RegExp는 테스트로 일치하며, 함수는 이름과 함께 호출되어 일치 여부를 반환합니다.

• test (Matcher): 경로가 주어진 값과 일치하는 모듈의 소스맵을 생성합니다. 기본값은 없습니다. test, include 또는 exclude로 제한하지 않으면 모든 모듈이 소스맵을 갖습니다. 모듈 자체 경로를 기준으로 하므로 청크나 번들 전체를 제외하는 데는 사용할 수 없습니다.
• include (Matcher): 주어진 값과 일치하는 모듈 경로에 대한 소스맵을 포함합니다.
• exclude (Matcher): 소스맵 생성에서 주어진 값과 일치하는 모듈을 제외합니다.
• append (string): 원래 애셋에 주어진 값을 추가합니다. 보통 #sourceMappingURL 주석입니다. [url]은 소스맵 파일의 URL로 대체됩니다.
• ignoreList (Matcher): 소스맵에서 지정된 값과 일치하는 소스 파일을 무시할지 여부를 결정합니다.
• module (boolean): 로더가 소스맵을 생성해야 하는지 여부를 나타냅니다(기본값은 true).
• moduleFilenameTemplate (string): output.devtoolModuleFilenameTemplate을 참고하세요.
• columns (boolean): 열 매핑을 사용해야 하는지 여부를 나타냅니다(기본값은 true).
• namespace (string): DevTools에서 여러 webpack 루트를 허용하는 네임스페이스 접두사입니다. output.devtoolNamespace를 참고하세요.
• noSources = false (boolean): 소스 파일 콘텐츠가 소스맵에 포함되지 않도록 합니다.
• sourceRoot (string): 소스맵의 sourceRoot 속성에 사용자 지정 값을 제공합니다.
• debugIds (boolean): true로 설정하면 소스 및 소스맵에 고유 ID가 생성되어 여러 빌드에서 소스맵을 식별하는 데 도움이 됩니다. 자세한 내용은 TC39 소스맵 디버그 ID 제안을 참고하세요.

Examples

다음 예시는 EvalSourceMapDevToolPlugin이 흔히 사용되는 사례를 보여줍니다.

Basic Use Case

다음 코드를 사용하여 설정 옵션 devtool: eval-source-map을 동등한 커스텀 플러그인 설정으로 바꿀 수 있습니다.

export default {
  // ...
  devtool: false,
  plugins: [new webpack.EvalSourceMapDevToolPlugin({})],
};

Exclude Vendor Maps

다음 코드는 node_modules에서 가져온 모든 모듈의 소스맵을 제외합니다.

new webpack.EvalSourceMapDevToolPlugin({
  exclude: /node_modules/,
});

HashedModuleIdsPlugin

이 플러그인은 해시가 모듈의 상대 경로를 기반으로 해 모듈 ID로 4개의 문자열이 생성됩니다.

new webpack.ids.HashedModuleIdsPlugin({
  // 옵션...
});

Options

이 플러그인은 다음 옵션을 지원합니다:

• context: 이름을 만들기 위한 컨텍스트 디렉터리 (절대 경로).

• hashFunction: 사용할 해싱 알고리즘, 기본 값은 'md4'입니다. Node.JS의 crypto.createHash의 모든 기능이 지원됩니다.

• hashDigest: 해시를 생성할 때 사용할 인코딩, 기본 값은 'base64'입니다. Node.JS의 hash.digest의 모든 인코딩이 지원됩니다.

  5.102.1+

  표준 Node.js 인코딩 외에도, 이 플러그인은 URL 안전 해시 값 생성에 유용한 'base64url'도 지원합니다. 커스텀 진법('base26', 'base32', 'base36', 'base49', 'base52', 'base58', 'base62')은 output.hashDigest에서만 사용 가능합니다.

• hashDigestLength: 사용할 해시 다이제스트의 접두사 길이, 기본 값은 4입니다. 생성된 일부 ID는 모듈 ID 충돌을 피하기 위해 여기에서 지정된 것보다 길 수 있습니다.

Usage

다음은 이 플러그인을 사용하는 방법의 예시입니다:

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

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

new webpack.ids.HashedModuleIdsPlugin({
  context: __dirname,
  hashFunction: "sha256",
  hashDigest: "hex",
  hashDigestLength: 20,
});

Using URL-safe encoding (5.102.1+):

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

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

new webpack.ids.HashedModuleIdsPlugin({
  context: __dirname,
  hashFunction: "md4",
  hashDigest: "base64url", // URL-safe encoding
  hashDigestLength: 8,
});

HotModuleReplacementPlugin

HMR로 알려져 있는 Hot Module Replacement을 활성화합니다.

Basic Usage

HMR을 활성화하는 것은 간단하며, 이 플러그인은 옵션이 없습니다.

new webpack.HotModuleReplacementPlugin();

IgnorePlugin

IgnorePlugin은 정규 표현식 또는 필터 함수와 일치하는 import 또는 require 호출에 대한 모듈 생성을 방지합니다.

Using regular expressions

• resourceRegExp: 리소스 테스트를 위한 정규 표현식
• contextRegExp: (선택) 컨텍스트 (디렉터리) 테스트를 위한 정규 표현식

new webpack.IgnorePlugin({ resourceRegExp, contextRegExp });

Using filter functions

• checkResource (resource, context)는 resource와 context를 인수로 받는 필터 함수로, 불리언 값을 반환해야 합니다.

new webpack.IgnorePlugin({
  checkResource(resource) {
    // 리소스를 사용합니다
    return true | false;
  },
});

Example of ignoring Moment Locales

moment 2.18 부터, 모든 로케일이 코어 라이브러리와 함께 번들로 제공됩니다 (깃허브 이슈를 참고하세요).

IgnorePlugin에 전달된 resourceRegExp 파라미터는 import 또는 require 되는 해석된 파일 이름 혹은 절대 모듈 이름에 대해 테스트 되지 않고, 가져오기가 실행되는 소스 코드 내에서 require 또는 import로 전달된 문자열 에 대해 테스트 됩니다. 예를 들어 node_modules/moment/locale/*.js를 제외하려는 경우 다음과 같은 작업이 수행되지 않습니다.

-new webpack.IgnorePlugin({ resourceRegExp: /moment\/locale\// });

moment는 아래의 코드로 가져오기 때문입니다.

import(`./locale/${name}`);

// or

require(`./locale/${name}`);

첫 번째 정규 표현식은 './locale/' 문자열과 일치해야 합니다. 그다음 두 번째 contextRegExp 파라미터를 사용하여 가져오기가 수행된 특정 디렉터리를 선택합니다. 다음은 로케일 파일이 무시되는 경우입니다.

new webpack.IgnorePlugin({
  resourceRegExp: /^\.\/locale$/,
  contextRegExp: /moment$/,
});

이는 'moment'로 끝나는 디렉터리에서 './locale'과 일치하는 모든 require 문이 무시됨을 의미합니다.

Internal webpack plugins

Webpack 내부적으로 사용하는 플러그인의 목록입니다.

내부 플러그인의 범주:

• environment
• compiler
• entry
• output
• source
• optimize

environment

컴파일러의 환경에 영향을 주는 플러그인입니다.

NodeEnvironmentPlugin

webpack.node.NodeEnvironmentPlugin()

컴파일러에 Node.js 스타일의 파일 시스템을 적용합니다.

compiler

컴파일러에 영향을 주는 플러그인입니다.

MemoryCachePlugin

MemoryCachePlugin()

모듈이 메모리에 캐시되는 컴파일러에 캐시를 추가합니다.

ProgressPlugin

ProgressPlugin(handler)

컴파일러에 훅을 하여 진행 정보를 추출합니다. handler는 (percentage: number, message: string) => void 서명이 있어야 합니다. Percentage는 0과 1 사이의 값으로 호출됩니다. 0은 시작, 1은 끝을 나타냅니다.

RecordIdsPlugin

RecordIdsPlugin()

레코드로부터 청크 아이디와 모듈을 저장하고 복원합니다.

entry

컴파일에 엔트리 청크를 포함하는 플러그인입니다.

EntryPlugin

EntryPlugin(context, entry, options)

컴파일에 엔트리 청크를 추가합니다. 청크의 이름은 options.name이고 오직 하나의 모듈만 포함합니다(의존성 추가). 모듈은 context (절대 경로)의 entry에서 확인됩니다.

PrefetchPlugin

PrefetchPlugin(context, request)

병렬 컴파일을 더 사용하기 위해서 의존성과 request를 프리페치합니다. 어떤 청크도 생성되지 않습니다. 모듈은 context (절대 경로)의 request에서 확인됩니다.

output

JsonpTemplatePlugin

web/JsonpTemplatePlugin()

청크는 JSONP-calls로 래핑되어 있습니다. 로딩 알고리즘은 엔트리 청크에 포함이 됩니다. <script> 태그를 추가함으로써 청크를 로드합니다.

옵션이 없으며 output.chunkLoading을 'jsonp'로 설정합니다. 출력 옵션을 통해 설정됩니다.

output.chunkLoadingGlobal이 JSONP 함수입니다.

output.publicPath는 청크를 로딩하기 위한 경로로 사용됩니다.

output.chunkFilename은 청크가 예상되는 파일 이름입니다.

NodeTemplatePlugin

node/NodeTemplatePlugin(options)

청크는 번들 모듈을 내보내는 Node.js 모듈로 래핑되어 있습니다. 엔트리 청크는 청크를 요구함으로써 로드됩니다.

options.asyncChunkLoading (boolean)은 output.chunkLoading으로 'require' 대신 'async-node'를 선택합니다.

LibraryTemplatePlugin

LibraryTemplatePlugin(name, target)

엔트리 청크들은 type 유형의 name 라이브러리로부터 꾸며집니다.

WebWorkerTemplatePlugin

webworker/WebWorkerTemplatePlugin()

청크는 importScripts에 의해 로드됩니다. 그렇지 않다면 JsonpTemplatePlugin과 비슷합니다.

옵션이 없으며 output.chunkLoading을 'import-scripts'로 설정합니다.

EvalDevToolModulePlugin

EvalDevToolModulePlugin(options)

//# sourceURL= 주석(options.sourceUrlComment, 기본값은 //# sourceURL=[url])이 달린 eval로 각 모듈을 감싸 모듈 템플릿을 꾸밉니다.

SourceMapDevToolPlugin

SourceMapDevToolPlugin(options)

각 청크에 대한 소스맵을 생성함으로써 템플릿들을 꾸밉니다.

options.filename은 소스맵의 파일 이름 템플릿입니다. [fullhash], [name], [id], [file] 및 [base]가 교체됩니다. 이 옵션이 없으면 소스맵은 DataUrl로 인라인 됩니다.

options.append, options.moduleFilenameTemplate, options.fallbackModuleFilenameTemplate 및 나머지 옵션은 SourceMapDevToolPlugin 페이지에서 설명합니다.

HotModuleReplacementPlugin

HotModuleReplacementPlugin()

Hot module replacement 대한 지원을 추가합니다. 런타임 코드를 추가한 템플릿을 꾸밉니다. `module.hot' API를 추가합니다.

옵션이 없으며 다음 출력 옵션을 읽습니다.

output.hotUpdateChunkFilename은 hot 업데이트 청크의 파일 이름입니다.

output.hotUpdateMainFilename은 hot 업데이트 매니페스트의 파일 이름입니다.

output.hotUpdateGlobal은 hot 업데이트를 로드하기 위한 전역 함수 이름입니다.

source

모듈의 소스 코드에 영향을 미치는 플러그인입니다.

APIPlugin

__webpack_* 변수(__webpack_public_path__, __webpack_require__, __webpack_modules__, __webpack_chunk_load__, __webpack_hash__, __webpack_nonce__, ...)를 모듈에서 접근 가능하게 하고, require.onError를 런타임 오류 핸들러(__webpack_require__.oe)에 매핑합니다.

CompatibilityPlugin

레거시 패턴을 재작성하여 다른 모듈 로더와의 호환성을 보장합니다. browserify 스타일의 require 위임자, 자체 __webpack_require__를 선언하는 사용자 코드, hashbang 라인 등이 해당됩니다.

ConstPlugin

파서에 의해 발사된 훅을 사용함으로써 dead branch를 추가로 제거를 가능하게 하려고 if (...)문과 삼항 연산자를 평가하여 true/false로 바꾸려고 시도합니다.

프로덕션 모드에는 dead branch와 관련하여 여러 최적화 들이 있습니다.

• Terser 이 수행한 최적화입니다.
• Webpack이 수행한 최적화 입니다.

Webpack은 조건문을 평가하려고 할 것입니다. 만약 성공한다면 dead branch가 제거됩니다. Webpck은 컴파일러가 알지 못하는 한 상수 폴딩을 할 수 없습니다. 다음 예시를 봅시다.

import { calculateTax } from "./tax";

const FOO = 1;
if (FOO === 0) {
  // dead branch
  calculateTax();
}

위의 예시에서, webpack은 branch를 자를 수 없지만, Terser는 할 수 있습니다. 그러나 만약 FOO가 DefinePlugin 을 사용하면, webpack은 성공할 것입니다.

import { calculateTax } from './tax';도 제거된다는 점을 언급해야 합니다. 왜냐하면 calculateTax() 호출이 dead branch에 있어 제거되었기 때문입니다.

ProvidePlugin

ProvidePlugin(definitions)

definitions의 각 name: request 항목에서, name이 모듈에서 사용되면 import ... from <request>/import(<request>)/require(<request>)로 로드된 모듈로 채워집니다.

NodeStuffPlugin

NodeStuffPlugin(options)

Node.js 모듈에서는 일반적으로 사용할 수 있는 항목을 제공합니다.

또한, module을 사용하는 경우에는 일부의 Node.js 항목으로 채워지도록 합니다.

RequireJsStuffPlugin

require.js에서는 일반적으로 사용할 수 있는 항목을 제공합니다.

require[js].config는 제거됩니다. require.version은 0.0.0입니다. requirejs.onError는 require.onError에 매핑이 됩니다.

NodeSourcePlugin

node/NodeSourcePlugin()

이 플러그인은 하위 호환성을 위해 유지되는 no-op입니다. webpack 5는 더 이상 process, Buffer 등의 Node.js 코어 모듈이나 전역 변수를 폴리필하지 않습니다.

NodeTargetPlugin

node/NodeTargetPlugin()

만약 Node.js 환경에서 번들을 실행하는 경우에는 플러그인을 사용해야 합니다.

만약 네이티브 모듈이 번들 되어있더라도 올바르게 로드되도록 보장합니다.

AMDPlugin

dependencies/AMDPlugin(options)

AMD 스타일의 define과 require 모듈을 제공합니다. 또한, require.amd, define.amd 와 webpack_amd_options## 를 파라미터로 전달된 options에 바인딩합니다.

CommonJsPlugin

dependencies/CommonJsPlugin

CommonJs 스타일의 require 모듈을 제공합니다.

RequireContextPlugin

dependencies/RequireContextPlugin()

Provides require.context. Alternative requests for files are derived from the configured resolve options (modules, extensions, mainFiles, enforceExtension).

RequireEnsurePlugin

dependencies/RequireEnsurePlugin()

require.ensure를 제공합니다.

RequireIncludePlugin

dependencies/RequireIncludePlugin()

require.include를 제공합니다.

DefinePlugin

DefinePlugin(definitions)

식별자에 대해 상수를 정의합니다.

definitions은 객체입니다.

optimize

webpack.optimize 네임스페이스 아래의 모든 플러그인은 mode 가 'none'으로 설정된 경우에만 사용해야 합니다. 그렇지 않다면 플러그인은 두 번 적용되어야 합니다.

LimitChunkCountPlugin

optimize/LimitChunkCountPlugin(options)

병합 청크의 제한된 청크 수는 `options.maxChunks'보다 작습니다.

options.chunkOverhead and options.entryChunkMultiplicator are still accepted but no longer have any effect.

전체적인 크기를 가장 많이 줄인 청크가 첫 번째로 병합됩니다. 만약 여러 조합이 같으면 병합된 크기가 작은 것이 선택됩니다.

MergeDuplicateChunksPlugin

optimize/MergeDuplicateChunksPlugin()

같은 모듈의 청크가 병합됩니다.

RemoveEmptyChunksPlugin

optimize/RemoveEmptyChunksPlugin()

모듈을 포함하지 않는 청크(런타임 청크나 엔트리 청크가 아닌 것)는 제거됩니다.

MinChunkSizePlugin

optimize/MinChunkSizePlugin({ minChunkSize })

각 청크의 최소 크기가 minChunkSize가 될 때까지 청크를 병합합니다.

ModuleConcatenationPlugin

ModuleConcatenationPlugin page에 대한 구체적인 내용을 확인해보세요.

FlagIncludedChunksPlugin

optimize/FlagIncludedChunksPlugin()

청크에 포함된 청크의 청크 아이디를 추가합니다. 불필요한 청크 로드를 제거할 수 있습니다.

RealContentHashPlugin

optimize/RealContentHashPlugin()

optimization.realContentHash 옵션이 활성화 될 때, webpack은 내부적으로 RealContentHashPlugin을 컴파일러에 추가합니다.

Hook

RealContentHashPlugin은 해시 업데이트를 커스터마이징할 수 있는 훅인 updateHash 5.8.0+를 제공합니다.

import webpack from "webpack";

const { RealContentHashPlugin } = webpack.optimize;
// ...
compiler.hooks.compilation.tap("MyPlugin", (compilation) => {
  const hooks = RealContentHashPlugin.getCompilationHooks(compilation);
  hooks.updateHash.tap("MyPlugin", (content, oldHash) => {
    // 이곳에서 원하는데로 해시를 계산할 수 있습니다.
  });
});

LimitChunkCountPlugin

코드를 작성할 때, 이미 필요한 것을 로드할 많은 코드 분할 지점을 추가했을 것입니다. 컴파일 후에 어떤 청크가 너무 작다는 것을 깨달을 것입니다. 이는 더 큰 HTTP 오버헤드를 만듭니다. LimitChunkCountPlugin은 청크를 합침으로써 그것들을 후속 처리할 수 있게 해줍니다.

new webpack.optimize.LimitChunkCountPlugin({
  // Options...
});

Options

다음의 옵션들이 지원됩니다.

maxChunks

number

청크의 최대 개수를 1보다 크거나 같도록 제한합니다. 1을 사용하는 것은 엔트리/메인 청크가 카운트에 포함될 때 추가적인 청크가 더해지는 것을 방지합니다.

webpack.config.js

import webpack from "webpack";

export default {
  // ...
  plugins: [
    new webpack.optimize.LimitChunkCountPlugin({
      maxChunks: 5,
    }),
  ],
};

minChunkSize

청크 크기를 지정한 제한 이상으로 유지하는 기능은 더 이상 이 플러그인의 기능이 아닙니다. 대신 MinChunkSizePlugin을 사용하세요.

ManifestPlugin

내장된 ManifestPlugin은 빌드에 대한 하나의 에셋 매니페스트를 생성합니다. WebpackManifestPlugin에서 포팅되었습니다.

webpack.config.js

new webpack.ManifestPlugin({
  // options...
});

Options

entrypoints

boolean = true

매니페스트에서 entrypoints 섹션 생성을 활성화합니다.

entrypoints가 활성화되어 있고 한 항목이 dependOn을 사용하는 경우

webpack.config.js

export default {
  entry: {
    entry1: {
      import: "./src/file_1.js",
      dependOn: "entry2",
    },
    entry2: "./src/file_2.js",
  },
  plugins: [
    new webpack.ManifestPlugin({
      filename: "manifest.json",
    }),
  ],
};

결과 매니페스트에는 부모/자식 관계 맵이 포함됩니다.

manifest.json

{
  "entrypoints": {
    "entry1": {
      "imports": ["entry1.js"],
      "parents": ["entry2"]
    },
    "entry2": {
      "imports": ["entry2.js"]
    }
  }
}

filename

string = manifest.json

디스크에 저장된 출력 파일의 파일 이름을 지정합니다. 기본적으로 플러그인은 output.path 디렉터리에 manifest.json 파일을 생성합니다.

filter

(item: ManifestItem) => boolean

매니페스트를 구성하는 파일을 필터링할 수 있습니다.

generate

(manifest: ManifestObject) => ManifestObject

매니페스트 객체를 수신하고 수정한 후 수정된 매니페스트를 반환합니다.

prefix

string = '[publicpath]'

매니페스트의 모든 키에 대한 경로 접두사를 지정합니다.

serialize

(manifest: ManifestObject) => string = (manifest) => JSON.stringify(manifest, null, 2)

매니페스트 객체를 수신하고 매니페스트 문자열을 반환합니다.

serialize를 사용하여 YAML과 같은 다른 형식을 출력합니다.

new webpack.ManifestPlugin({
  serialize(manifest) {
    return YAML.stringify(manifest, 4);
  },
});

Plugins

Webpack에는 많은 플러그인 인터페이스가 있습니다. Webpack 자체에 있는 대부분의 기능은 플러그인 인터페이스를 사용합니다. 이런점이 webpack을 유연하게 만듭니다.

아래 플러그인들은 기능별로 분류되어 있습니다. 대부분은 webpack에 포함되어 있어 new webpack.SomePlugin()으로 사용할 수 있으며, *-webpack-plugin 이름의 페이지에 있는 것들은 별도로 설치가 필요한 패키지입니다.

Sources and modules

Output and assets

Chunks and optimization

Module Federation

Development and diagnostics

더 많은 써드 파티 플러그인을 찾고 싶다면, awesome-webpack을 참고하세요.

MergeDuplicateChunksPlugin

동일한 모듈을 포함하는 청크를 병합합니다. 이 플러그인은 webpack의 내부 최적화의 일부로 기본적으로 활성화되어 있습니다. 이 플러그인을 공개적으로 내보내면 개발자는 병합이 발생하는 stage를 구성할 수 있습니다. 이는 청크 병합이 SplitChunksPlugin 이후에 실행되어야 할 때 유용합니다.

new webpack.optimize.MergeDuplicateChunksPlugin({
  // 옵션...
});

Options

stage

number

중복 청크 병합이 실행되는 최적화 단계를 제어합니다. 기본적으로 병합은 SplitChunksPlugin 이전에 발생합니다. stage를 10(SplitChunksPlugin의 단계) 보다 크게 설정하면 병합이 그 이후에 실행됩니다. 10 값은 사용자 플러그인이 먼저 적용되기 때문에 여전히 이전에 실행됩니다. 내장 인스턴스(단계 -10)는 활성 상태를 유지하므로, 이 설정은 두 번째 병합 패스를 추가합니다.

webpack.config.js

import webpack from "webpack";

export default {
  // ...
  plugins: [
    new webpack.optimize.MergeDuplicateChunksPlugin({
      stage: 11, // run after SplitChunksPlugin (stage 10)
    }),
  ],
};

MinChunkSizePlugin

minChunkSize보다 작은 청크를 병합하여 청크 크기를 설정한 한계 이상으로 유지합니다.

new webpack.optimize.MinChunkSizePlugin({
  minChunkSize: 10000, // 최소 문자 수
});

MinimizerWebpackPlugin

This plugin minifies your assets in a webpack build. It ships with several built-in minimizers covering JavaScript, JSON, HTML, CSS, and images — pick one with the minify option and target the right files with test.

JavaScript minimizers:

• terser — MinimizerPlugin.terserMinify (default). The same JavaScript-based minifier that webpack uses out of the box; produces small, well-tested output and supports the full set of extractComments modes.
• uglify-js — MinimizerPlugin.uglifyJsMinify. ES5-only minifier, useful when you specifically need UglifyJS-compatible output. Requires npm install --save-dev uglify-js.
• @swc/core — MinimizerPlugin.swcMinify. A very fast Rust-based JavaScript/TypeScript minifier. Requires npm install --save-dev @swc/core.
• esbuild — MinimizerPlugin.esbuildMinify. An extremely fast JS bundler/minifier; legal comments are always preserved (no extractComments support). Requires npm install --save-dev esbuild.

JSON minimizer:

• JSON.stringify — MinimizerPlugin.jsonMinify. Built in (no extra dependency); supports space and replacer options.

HTML minimizers:

• webpack's own — webpack.html.syntax.htmlMinify. Ships with webpack (>= 5.111.0), so it needs no extra dependency, and it is the one that minifies what a document nests: an inline <style>, every style="", a <script>, an <svg> subtree. See webpack's own minimizers.
• html-minifier-terser — MinimizerPlugin.htmlMinifierTerser. JavaScript-based, no native dependency. Requires npm install --save-dev html-minifier-terser.
• @swc/html — MinimizerPlugin.swcMinifyHtml (full HTML documents) and MinimizerPlugin.swcMinifyHtmlFragment (HTML fragments, e.g. <template> content). Very fast Rust-based platform for the Web. Requires npm install --save-dev @swc/html.
• @minify-html/node — MinimizerPlugin.minifyHtmlNode. A Rust HTML minifier optimised for speed and effectiveness. Requires npm install --save-dev @minify-html/node.

CSS minimizers:

• webpack's own — webpack.css.syntax.cssMinify. Ships with webpack (>= 5.111.0), so it needs no extra dependency, and it minifies the CSS a stylesheet or a document nests. See webpack's own minimizers.
• cssnano — MinimizerPlugin.cssnanoMinify. Built on top of PostCSS. Requires npm install --save-dev cssnano postcss.
• csso — MinimizerPlugin.cssoMinify. A CSS minifier with structural optimisations. Requires npm install --save-dev csso.
• clean-css — MinimizerPlugin.cleanCssMinify. A widely-used CSS optimiser. Requires npm install --save-dev clean-css.
• esbuild — MinimizerPlugin.esbuildMinifyCss. Very fast CSS minification using esbuild's CSS loader. Requires npm install --save-dev esbuild.
• lightningcss — MinimizerPlugin.lightningCssMinify. A Rust-based CSS parser, transformer, and minifier. Requires npm install --save-dev lightningcss.
• @swc/css — MinimizerPlugin.swcMinifyCss. A very fast Rust-based CSS minifier. Requires npm install --save-dev @swc/css.

Image minimizers:

• sharp — MinimizerPlugin.sharpMinify. Re-encodes an image as the format its name already claims (avif, gif, heif, jp2, jpeg, png, tiff, webp), and can resize, rotate, flip, grayscale, blur or sharpen on the way — from the options or from the asset's own name. Requires npm install --save-dev sharp.
• svgo — MinimizerPlugin.svgoMinify. Minifies SVG, including an asset/inline SVG that no test can match. Requires npm install --save-dev svgo.
• imagemin — MinimizerPlugin.imageminMinify. Runs the imagemin plugins you name. Requires npm install --save-dev imagemin plus each plugin. Pair it with MinimizerPlugin.imageminGenerate under generate when a plugin converts the format, since only that can rename the asset.
• @napi-rs/image — MinimizerPlugin.napiRsImageMinify. Rust codecs with no system dependency; recompresses png losslessly with oxipng and jpeg with mozjpeg, and can resize, turn, mirror, grayscale, invert or blur on the way — from the options or from the asset's own name. Requires npm install --save-dev @napi-rs/image.

These only minify — they never change an image's format or name; see Images.

Transport encodings:

• zlib and anything shaped like it — MinimizerPlugin.compress. Compresses an asset so a server can serve it under Content-Encoding. Takes algorithm — a zlib function's name (gzip, brotliCompress, deflate, zstdCompress, …) or one of your own — and compressionOptions for it, and needs no extra dependency. Give it to minify to compress an asset in place, or to generate as an asset generator to write the compressed file beside the original; either way it puts itself after the minimizers, through a getStage of its own.

All of the non-default minimizers are declared as optional peer dependencies — install only the ones you actually use. One plugin instance covers several languages at once: give minify an array and each minimizer is offered only the assets its own filter accepts, so JS, CSS, HTML and JSON share a single worker pool (see Examples).

Getting Started

Webpack v5 comes with the latest minimizer-webpack-plugin out of the box. If you are using Webpack v5 or above and wish to customize the options, you will still need to install minimizer-webpack-plugin. Using Webpack v4, you have to install terser-webpack-plugin v4 (minimizer-webpack-plugin is only published for Webpack v5+).

To begin, you'll need to install minimizer-webpack-plugin:

npm install minimizer-webpack-plugin --save-dev

or

yarn add -D minimizer-webpack-plugin

or

pnpm add -D minimizer-webpack-plugin