Datagrid and Charting for Enterprise Applications

Printable

Introduction

컴파일 절차를 커스터마이즈 하기 위해 다양한 인터페이스를 사용할 수 있습니다. 인터페이스 간에 겹치는 기능도 존재합니다. 예를 들면, 구성 옵션은 CLI 플래그를 통해 사용할 수 있지만 다른 옵션은 단일 인터페이스를 통해서만 존재합니다. 아래의 정보가 시작하는 데 도움을 줄 것입니다.

CLI

명령 줄 인터페이스(CLI)는 빌드를 구성하고 상호작용하는 데 사용됩니다. 특히 초기 프로토타이핑이나 프로파일링의 경우 유용합니다. 대부분의 경우 CLI는 설정 파일과 --env 같은 몇 가지 플래그를 사용하여 프로세스를 시작하는 데 사용됩니다.

CLI에 대해 더 알아보세요!

Module

webpack을 사용하여 모듈을 처리할 때 메소드나 변수같이 다양한 지원되는 모듈 구문을 이해하는 것이 중요합니다.

모듈에 대해 더 알아보세요!

Node

대부분의 사용자는 설정 파일과 CLI를 함께 사용하는 것만으로도 충분하지만, Node 인터페이스를 통해 컴파일을 보다 세밀하게 제어할 수 있습니다. 여기에는 다중 설정 전달과 프로그래밍 방식으로 실행 또는 감시, 통계 수집이 포함됩니다.

Node API에 대해 더 알아보세요!

Loaders

로더는 모듈의 소스 코드에 적용되는 변환입니다. 소스 코드를 매개 변수로 받고 변환이 적용된 해당 코드의 새 버전을 반환하는 함수로 작성됩니다.

로더에 대해 더 알아보세요!

Plugins

플러그인 인터페이스를 통해 컴파일 프로세스에 직접 접근할 수 있습니다. 플러그인은 컴파일 동안 서로 다른 지점에서 실행되는 수명주기 훅에 핸들러를 등록할 수 있습니다. 각각의 훅이 실행될 때 플러그인은 현재 컴파일 상태에 대한 모든 액세스 권한을 갖습니다.

플러그인에 대해 더 알아보세요!

Command Line Interface

이 설정을 적절하게 사용하고 쉽게 배포하려면 webpack.config.js로 webpack을 설정 할 수 있습니다. CLI로 전송된 모든 파라미터는 설정 파일의 해당 파라미터에 매핑됩니다.

webpack 및 CLI를 아직 설치하지 않은 경우 설치 가이드를 읽어보세요.

Commands

webpack-cli는 webpack을 더 쉽게 사용할 수 있도록 다양한 명령을 제공합니다. 기본적으로 webpack은 다음과 같은 명령어를 제공합니다.

명령어	사용법	설명
`build`	`build\|bundle\|b [entries...] [options]`	webpack을 실행합니다. (기본 명령어, 생략 가능).
`configtest`	`configtest\|t [config-path]`	webpack 설정을 검증합니다.
`help`	`help\|h [command] [option]`	명령어 및 옵션에 대한 도움말을 표시합니다.
`info`	`info\|i [options]`	시스템 정보를 출력합니다.
`init`	`init\|create\|c\|new\|n [generation-path] [options]`	새로운 webpack 프로젝트를 초기화합니다.
`loader`	`loader\|l [output-path] [options]`	로더를 스캐폴드합니다.
`plugin`	`plugin\|p [output-path] [options]`	플러그인을 스캐폴드합니다.
`serve`	`serve\|server\|s [options]`	`webpack-dev-server`를 실행합니다.
`version`	`version\|v [commands...]`	`webpack`, `webpack-cli` 및 `webpack-dev-server`의 버전 넘버를 출력합니다.
`watch`	`watch\|w [entries...] [options]`	webpack을 실행하고 파일 변경을 감지합니다.

Build

webpack을 실행합니다. (기본 명령어, 생략 가능).

npx webpack build [options]

example

npx webpack build --config ./webpack.config.js --stats verbose

Init

새 webpack 프로젝트를 초기화하기 위해 사용합니다.

npx webpack init [generation-path] [options]

예시

npx webpack init ./my-app --force --template=default

Generation Path

설정을 생성할 위치입니다. 기본값은 process.cwd()입니다.

Options

-t, --template

string = 'default'

생성할 템플릿의 이름입니다.

-f, --force

boolean

질문 없이 프로젝트를 생성합니다. 활성화하면 각 질문에 대한 기본 답변을 사용합니다.

Loader

로더를 스캐폴드합니다.

npx webpack loader [output-path] [options]

example

npx webpack loader ./my-loader --template=default

Output Path

출력 디렉터리 경로, 예) ./loader-name.

Options

-t, --template

string = 'default'

템플릿의 유형입니다.

Plugin

플러그인을 스캐폴드합니다.

npx webpack plugin [output-path] [options]

example

npx webpack plugin ./my-plugin --template=default

Output Path

출력 디렉터리 경로, 예) ./plugin-name.

Options

-t, --template

string = 'default'

템플릿의 유형입니다.

Info

시스템에 대한 정보를 출력합니다.

npx webpack info [options]

예시

npx webpack info --output json --addition-package postcss

Options for info

-a, --additional-package

string

출력에 패키지를 추가합니다.

예시

npx webpack info --additional-package postcss

-o, --output

string : 'json' | 'markdown'

지정된 형식으로 출력을 가져옵니다.

예시

npx webpack info --output markdown

Configtest

webpack 설정을 검증합니다.

npx webpack configtest [config-path]

예시

npx webpack configtest ./webpack.config.js

Config Path

webpack 설정 파일의 경로입니다. 기본값은 ./webpack.config.js입니다.

Serve

webpack dev server를 실행합니다.

npx webpack serve [options]

example

npx webpack serve --static --open

Watch

webpack을 실행하고 파일 변경을 감지합니다.

npx webpack watch [options]

example

npx webpack watch --mode development

Flags

기본적으로 webpack은 다음 플래그와 함께 제공됩니다.

플래그 / 별칭	타입	설명
`--entry`	string[]	애플리케이션의 엔트리 포인트입니다. (예: `./src/main.js`)
`--config, -c`	string[]	webpack 설정 파일의 경로를 제공합니다. (예: `./webpack.config.js`)
`--config-name`	string[]	사용할 설정의 이름입니다.
`--name`	string	사용할 설정의 이름. 복수의 설정을 로드할 때 사용합니다.
`--color`	boolean	콘솔에서 색상 활성화
`--merge, -m`	boolean	`webpack-merge`를 사용하여 둘 이상의 구성을 병합합니다.
`--env`	string[]	함수일 때 설정에 전달된 환경입니다.
`--define-process-env-node-env`	string	`process.env.NODE_ENV`를 지정된 값으로 설정합니다.
`--progress`	boolean, string	빌드 중 컴파일 진행률을 출력합니다.
`--help`	boolean	지원되는 플래그 및 명령 목록을 출력합니다.
`--output-path, -o`	string	webpack에 의해 생성된 파일의 출력 위치입니다. (예: `./dist`)
`--target, -t`	string[]	빌드 대상을 설정합니다.
`--watch, -w`	boolean	파일 변경 사항을 확인합니다.
`--watch-options-stdin`	boolean	stdin 스트림이 종료되면 감시를 중단합니다.
`--devtool, -d`	string	소스 맵 생성 여부와 방법을 제어합니다.
`--json, -j`	boolean, string	결과를 JSON으로 출력하거나 파일으로 저장합니다.
`--mode`	string	webpack에 전달할 모드를 정의합니다.
`--version, -v`	boolean	현재 버전을 가져옵니다.
`--stats`	boolean, string	webpack에 통계 처리 방법을 지시합니다.
`--disable-interpret`	boolean	설정 파일을 로드할 때 해석을 사용하지 않도록 설정합니다.
`--fail-on-warnings`	boolean	webpack의 경고에서 0이 아닌 종료 코드로 webpack-cli 프로세스를 중지합니다.
`--analyze`	boolean	번들 정보를 얻기 위해 `webpack-bundle-analyzer` 플러그인을 호출합니다.
`--extends, -e`	string[]	기존 설정을 확장합니다.

Negated Flags

플래그	설명
`--no-color`	콘솔에서 모든 색상을 비활성화합니다.
`--no-hot`	설정을 통해 활성화한 경우 핫 리로딩을 비활성화합니다.
`--no-stats`	webpack에서 내보낸 컴파일 통계를 비활성화합니다.
`--no-watch`	파일 변경을 감시하지 않습니다.
`--no-devtool`	소스 맵을 생성하지 않습니다.
`--no-watch-options-stdin`	stdin 스트림이 종료되어도 감시를 중단하지 않습니다.

Core Flags

CLI v4와 webpack v5부터 CLI는 webpack 코어에서 전체 설정 스키마를 가져옵니다. 커맨드 라인에서 거의 모든 설정 옵션을 조정할 수 있습니다.

CLI v4를 통한 webpack v5에서 지원하는 모든 코어 플래그 목록입니다. - 링크

예를 들어, 프로젝트에서 성능 힌트를 활성화하려면 설정에서 이 옵션을 사용할 수 있습니다. 코어 플래그를 사용하면 아래와 같이 할 수 있습니다.

npx webpack --performance-hints warning

Usage

With configuration file

npx webpack [--config webpack.config.js]

설정 파일의 옵션은 configuration을 참고하세요.

Without configuration file

npx webpack --entry <entry> --output-path <output-path>

예시

npx webpack --entry ./first.js --entry ./second.js --output-path /build

entry

프로젝트 빌드를 위한 엔트리 포인트 파일명 또는 명명된 파일명 모음입니다. 복수의 엔트리를 전달할 수 있습니다 (모든 항목은 시작 시 로드됩니다). 다음은 CLI를 통해 엔트리 파일을 지정하는 여러 가지 방법입니다.

npx webpack --entry-reset ./first-entry.js

npx webpack --entry-reset --entry ./first-entry.js

npx webpack --entry-reset ./first-entry.js ./other-entry.js

npx webpack --entry-reset --entry ./first-entry.js ./other-entry.js

output-path

저장할 번들 파일의 경로입니다. 설정 옵션의 output.path에 매핑됩니다.

예시

프로젝트 구조가 다음과 같다고 가정해봅니다.

.
├── dist
├── index.html
└── src
    ├── index.js
    ├── index2.js
    └── others.js

npx webpack ./src/index.js --output-path dist

이 명령어는 소스 코드와 엔트리를 함께 index.js로 번들합니다. 출력 번들 파일의 경로는 dist입니다.

asset main.js 142 bytes [compared for emit] [minimized] (name: main)
./src/index.js 30 bytes [built] [code generated]
./src/others.js 1 bytes [built] [code generated]
webpack 5.1.0 compiled successfully in 187 ms

npx webpack ./src/index.js ./src/others2.js --output-path dist/

이것은 두 파일을 별도의 엔트리 포인트로 포함하는 번들을 생성합니다.

asset main.js 142 bytes [compared for emit] [minimized] (name: main)
./src/index.js 30 bytes [built] [code generated]
./src/others2.js 1 bytes [built] [code generated]
./src/others.js 1 bytes [built] [code generated]
webpack 5.1.0 compiled successfully in 198 ms

Default Configurations

CLI는 프로젝트 경로에서 일부 기본 설정을 찾습니다. 아래는 CLI에서 찾는 설정 파일입니다.

오름차순으로 우선 조회합니다.

예 - 설정 파일 조회 순서는 .webpack/webpackfile > .webpack/webpack.config.js > webpack.config.js 입니다.

'webpack.config',
'.webpack/webpack.config',
'.webpack/webpackfile',

Common Options

help

CLI에서 사용 가능한 기본 명령 및 플래그 나열

webpack help [command] [option] 및 webpack [command] --help 모두 유효합니다.

npx webpack --help

# or

npx webpack help

CLI에서 지원하는 모든 명령 및 플래그를 나열

npx webpack --help=verbose

특정 명령어 또는 옵션에 대한 도움말 보기

npx webpack help --mode

version

설치된 패키지 및 하위 패키지의 버전 표시

사용 중인 webpack 및 webpack-cli의 버전을 검사하려면 다음 명령을 실행하세요.

npx webpack --version

# or

npx webpack version

다음 결과가 출력됩니다.

webpack 5.31.2
webpack-cli 4.6.0

webpack-dev-server가 설치된 경우 해당 버전도 출력합니다.

webpack 5.31.2
webpack-cli 4.6.0
webpack-dev-server 3.11.2

@webpack-cli/info와 같은 webpack-cli의 하위 패키지 버전을 검사하려면 다음과 같은 명령을 실행합니다.

npx webpack info --version

그러면 다음 결과가 출력됩니다.

@webpack-cli/info 1.2.3
webpack 5.31.2
webpack-cli 4.6.0
webpack-dev-server 3.11.2

config

설정 파일을 사용하여 소스 빌드

기본값 중 하나인 webpack.config.js가 아닌 다른 configuration 파일을 지정합니다.

npx webpack --config example.config.js

config-name

설정 파일이 여러 설정을 내보내는 경우 --config-name을 사용하여 실행할 설정을 지정할 수 있습니다.

아래와 같은 webpack.config.js를 생각해 봅시다.

module.exports = [
  {
    output: {
      filename: './dist-first.js',
    },
    name: 'first',
    entry: './src/first.js',
    mode: 'development',
  },
  {
    output: {
      filename: './dist-second.js',
    },
    name: 'second',
    entry: './src/second.js',
    mode: 'development',
  },
  {
    output: {
      filename: './dist-third.js',
    },
    name: 'third',
    entry: './src/third.js',
    mode: 'none',
    stats: 'verbose',
  },
];

second 설정만 실행합니다.

npx webpack --config-name second

여러 값을 전달할 수도 있습니다.

npx webpack --config-name first --config-name second

merge

--merge의 도움으로 두 개 이상의 서로 다른 webpack 설정을 병합할 수 있습니다.

npx webpack --config ./first.js --config ./second.js --merge

extends

webpack-cli v5.1.0+

--extends를 사용하여 기존 webpack 설정을 확장할 수 있습니다.

npx webpack --extends ./base.webpack.config.js

설정 확장에서 자세한 내용을 읽어보세요.

json

webpack 결과를 JSON으로 출력

npx webpack --json

통계를 출력하는 대신 json으로 저장

npx webpack --json stats.json

다른 모든 경우에 webpack은 번들, 청크 및 타이밍 세부 정보를 보여주는 일련의 통계를 출력합니다. 이 옵션을 사용하면 출력이 JSON 객체가 될 수 있습니다. webpack의 분석 도구, chrisbateman의 webpack-visualizer 또는 th0r의 webpack-bundle-analyzer 에서 이 응답이 수락됩니다. 이러한 분석 도구는 JSON을 가져와서 빌드의 모든 세부 정보를 그래픽 형식으로 제공합니다.

Environment Options

webpack 설정이 함수를 내보낼 때"environment"를 설정에 전달할 수 있습니다.

env

npx webpack --env production    # env.production = true

--env 인수는 복수의 값을 허용합니다.

호출	결과 환경
`npx webpack --env prod`	`{ prod: true }`
`npx webpack --env prod --env min`	`{ prod: true, min: true }`
`npx webpack --env platform=app --env production`	`{ platform: "app", production: true }`
`npx webpack --env foo=bar=app`	`{ foo: "bar=app"}`
`npx webpack --env app.platform="staging" --env app.name="test"`	`{ app: { platform: "staging", name: "test" }`

위에 표시된 사용자 정의 env 외에도 env 하위에는 webpack 설정 내에서 사용되는 몇 가지 내장 기능이 있습니다.

환경 변수	설명
`WEBPACK_SERVE`	`serve\|server\|s`를 사용하고 있으면 `true`
`WEBPACK_BUILD`	`build\|bundle\|b`를 사용하고 있으면 `true`
`WEBPACK_WATCH`	`--watch\|watch\|w`를 사용하고 있으면 `true`

번들 코드 내에서는 이러한 내장 환경 변수에 접근할 수 없는 점을 알아두세요.

module.exports = (env, argv) => {
  return {
    mode: env.WEBPACK_SERVE ? 'development' : 'production',
  };
};

node-env

--node-env 옵션을 사용하여 process.env.NODE_ENV를 설정할 수 있으며, 이는 사용자 코드와 webpack 설정 모두에서 사용할 수 있습니다.

npx webpack --node-env production   # process.env.NODE_ENV = 'production'

define-process-env-node-env

webpack-cli v5+의 경우.

process.env.NODE_ENV를 설정하기 위한 --node-env의 별칭입니다.

npx webpack --define-process-env-node-env production   # process.env.NODE_ENV = 'production'

설정에 mode 옵션이 지정되지 않은 경우 --define-process-env-node-env 옵션을 사용하여 mode를 설정할 수 있습니다. 예를 들어 --define-process-env-node-env production을 사용하면 process.env.NODE_ENV와 mode가 모두 `production'으로 설정됩니다.

설정이 함수를 내보내는 경우 함수가 반환된 후 --define-process-env-node-env 값이 mode에 할당됩니다. 즉, mode는 함수 인수(env 및 argv)에서 사용할 수 없습니다. 그러나 --define-process-env-node-env의 값은 argv.nodeEnv로 접근할 수 있으며 그에 따라 사용할 수 있습니다.

module.exports = (env, argv) => {
  console.log(argv.defineProcessEnvNodeEnv); // 'production' --define-process-env-node-env production이 사용되는 경우
  return {
    // 당신의 설정
  };
};

Configuration Options

파라미터	설명	입력 타입	기본값
`--config`	설정 파일 경로	string[]	Default Configs
`--config-name`	사용할 설정의 이름	string[]	-
`--env`	함수일 때 설정에 전달된 환경	string[]	-

Analyzing Bundle

webpack-bundle-analyzer를 사용하여 webpack에서 내보낸 출력 번들을 분석할 수 있습니다. --analyze 플래그를 사용하여 CLI를 통해 호출 할 수 있습니다.

npx webpack --analyze

Progress

webpack 컴파일 진행 상황을 확인하려면 --progress 플래그를 사용합니다.

npx webpack --progress

진행 단계에 대한 프로필 데이터를 수집하려면 --progress 플래그에 profile을 값으로 전달할 수 있습니다.

npx webpack --progress=profile

Pass CLI arguments to Node.js

Node.js 프로세스에 직접 인수를 전달하려면 NODE_OPTIONS 옵션을 사용할 수 있습니다.

예를 들어, Node.js 프로세스의 메모리 제한을 4GB로 늘리려면 아래와 같이 사용합니다.

NODE_OPTIONS="--max-old-space-size=4096" webpack

또한 Node.js 프로세스에 복수의 옵션을 전달할 수 있습니다.

NODE_OPTIONS="--max-old-space-size=4096 -r /path/to/preload/file.js" webpack

Exit codes and their meanings

종료 코드	설명
`0`	성공
`1`	webpack 오류
`2`	설정 / 옵션 문제 또는 내부 오류

CLI Environment Variables

환경 변수	설명
`WEBPACK_CLI_SKIP_IMPORT_LOCAL`	`true`이면 `webpack-cli`의 로컬 인스턴스 사용을 건너뜁니다.
`WEBPACK_CLI_FORCE_LOAD_ESM_CONFIG`	`true`이면 ESM 설정을 강제로 로드합니다.
`WEBPACK_PACKAGE`	CLI에서 사용자 정의 webpack 버전을 사용합니다.
`WEBPACK_DEV_SERVER_PACKAGE`	CLI에서 사용자 정의 webpack-dev-server 버전을 사용합니다.
`WEBPACK_CLI_HELP_WIDTH`	도움말 출력에 사용자 정의 너비를 사용합니다.

WEBPACK_CLI_FORCE_LOAD_ESM_CONFIG=true npx webpack --config ./webpack.config.esm

WEBPACK_PACKAGE

CLI에서 사용자 정의 webpack 버전을 사용합니다. package.json에서 다음 내용을 고려합니다.

{
  "webpack": "^4.0.0",
  "webpack-5": "npm:webpack@^5.32.0",
  "webpack-cli": "^4.5.0"
}

webpack v4.0.0을 사용하려면 아래 명령을 사용합니다.

npx webpack

webpack v5.32.0을 사용하려면 아래 명령을 사용합니다.

WEBPACK_PACKAGE=webpack-5 npx webpack

Troubleshooting

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for ./webpack.config.ts

TypeScript에서 기본 ESM을 사용하는 경우 이와 같은 오류가 발생할 수 있습니다 (예: package.json의 type: "module").

webpack-cli는 CommonJS 및 ESM 형식의 설정을 모두 지원하며, 처음에는 require()를 사용하여 설정을 로드하려고 시도합니다. 일단 실패하면 'ERR_REQUIRE_ESM' (이 경우의 특수한 코드) import()를 사용하여 설정 로드를 시도합니다. 그러나, import() 메소드는 loader 훅이 활성화되어 있지 않으면 ts-node에서 작동하지 않습니다. (TypeStrong/ts-node#1007에 설명되어 있습니다).

위의 오류를 수정하려면 다음 명령을 사용하세요.

NODE_OPTIONS="--loader ts-node/esm" npx webpack --entry ./src/index.js --mode production

자세한 내용은 TypeScript로 webpack 설정 작성에 대한 문서를 참고하세요.

Node Interface

webpack은 Node.js 런타임에서 직접 사용할 수 있는 Node.js API를 제공합니다.

Node.js API는 모든 보고 및 오류 처리가 수동으로 처리되어야 하므로, webpack이 컴파일 부분만 수행하고 빌드 또는 개발 프로세스는 사용자 정의하는 경우 유용합니다. 이러한 이유로 stats 설정 옵션은 webpack() 호출에 영향을 미치지 않습니다.

Installation

webpack Node.js API 사용을 시작하려면 먼저 webpack을 설치하세요.

npm install --save-dev webpack

그런 다음 Node.js 스크립트에 webpack 모듈을 요청합니다.

const webpack = require('webpack');

또는 ES2015를 선호하다면 아래처럼 사용하세요.

import webpack from 'webpack';

webpack()

가져온 webpack 함수는 webpack 설정 객체를 제공하며 콜백 함수가 제공되면 webpack 컴파일러를 실행합니다.

const webpack = require('webpack');

webpack({}, (err, stats) => {
  if (err || stats.hasErrors()) {
    // ...
  }
  // 프로세싱 완료
});

Compiler Instance

webpack 러너 함수에 콜백을 전달하지 않으면 webpack Compiler 인스턴스를 반환합니다. 이 인스턴스를 사용하여 webpack 러너를 수동으로 트리거 하거나, 빌드하고 변경 사항을 감시할 수 있습니다. CLI와 비슷합니다. Compiler 인스턴스는 다음 메소드를 제공합니다.

.run(callback)
.watch(watchOptions, handler)

특정 작업을 위임하기 위해 자식 컴파일러를 생성할 수 있지만, 일반적으로 마스터 Compiler 인스턴스는 하나만 생성됩니다. Compiler는 궁극적으로 라이프 사이클을 계속 실행하기 위해 최소한의 기능만을 수행하는 함수입니다. 이는 등록된 플러그인에 모든 로딩, 번들링 및 쓰기 작업을 위임합니다.

Compiler 인스턴스의 hooks 속성은 Compiler 라이프 사이클의 훅 이벤트에 플러그인을 등록하는 데 사용됩니다. WebpackOptionsDefaulter 및 WebpackOptionsApply 유틸리티는 webpack에서 모든 내장 플러그인으로 Compiler 인스턴스를 설정하는 데 사용됩니다.

그런 다음 run 메소드를 사용하여 모든 컴파일 작업을 시작합니다. 완료되면 지정된 callback 함수가 실행됩니다. 최종 통계 및 오류 로깅은 이 callback 함수에서 수행되어야 합니다.

Run

Compiler 인스턴스에서 run 메소드를 호출하는 것은 위에서 언급한 빠른 실행 메소드와 매우 유사합니다.

const webpack = require('webpack');

const compiler = webpack({
  // ...
});

compiler.run((err, stats) => {
  // ...

  compiler.close((closeErr) => {
    // ...
  });
});

Watching

watch 메소드를 호출하면 webpack 러너를 트리거 하지만, 곧이어 변경 사항을 감시합니다 (webpack --watch CLI와 유사합니다). webpack이 변경사항을 감지하는 즉시 다시 실행합니다. Watching 인스턴스를 반환합니다.

watch(watchOptions, callback);

const webpack = require('webpack');

const compiler = webpack({
  // ...
});

const watching = compiler.watch(
  {
    // 예시
    aggregateTimeout: 300,
    poll: undefined,
  },
  (err, stats) => {
    // watch/build 결과를 여기에 출력...
    console.log(stats);
  }
);

Watching 옵션은 여기에 자세히 설명되어 있습니다.

Close `Watching`

watch 메소드는 .close(callback) 메소드를 노출하는 Watching 인스턴스를 반환합니다. 이 메소드를 호출하면 감시가 종료됩니다.

watching.close((closeErr) => {
  console.log('Watching Ended.');
});

Invalidate `Watching`

watching.invalidate를 사용하면 감시 프로세스를 중지하지 않고 현재 컴파일 라운드를 수동으로 무효화할 수 있습니다.

watching.invalidate();

Stats Object

webpack() callback의 두 번째 인수로 전달되는 stats 객체는 코드 컴파일 프로세스에 대한 좋은 정보 소스입니다. 여기에는 다음이 포함됩니다.

오류 및 경고(있는 경우)
타이밍
모듈 및 청크 정보

webpack CLI는 이 정보를 사용하여 보기 좋은 형식으로 사용자의 콘솔에 출력을 표시합니다.

이 stats 객체는 다음 메소드를 노출합니다.

stats.hasErrors()

컴파일하는 동안 오류가 있었는지 확인하는 데 사용할 수 있습니다. true 또는 false를 반환합니다.

stats.hasWarnings()

컴파일하는 동안 경고가 있었는지 확인하는 데 사용할 수 있습니다. true 또는 false를 반환합니다.

stats.toJson(options)

컴파일 정보를 JSON 객체로 반환합니다. options는 문자열(사전 설정) 또는 보다 세분화된 제어를 위한 객체일 수 있습니다.

stats.toJson('minimal');

stats.toJson({
  assets: false,
  hash: true,
});

사용 가능한 모든 옵션과 사전 설정은 통계 문서에 설명되어 있습니다.

다음은 이 함수의 출력 예시입니다.

stats.toString(options)

컴파일 정보의 형식화된 문자열을 반환합니다. (CLI 출력과 유사합니다.)

옵션은 stats.toJson(options)과 동일하지만 한 가지 추가 사항이 있습니다.

stats.toString({
  // 콘솔 색상 추가
  colors: true,
});

다음은 stats.toString() 사용법의 예시입니다.

const webpack = require('webpack');

webpack(
  {
    // ...
  },
  (err, stats) => {
    if (err) {
      console.error(err);
      return;
    }

    console.log(
      stats.toString({
        chunks: false, // 빌드를 훨씬 조용하게 만듭니다.
        colors: true, // 콘솔에 색상을 표시합니다.
      })
    );
  }
);

MultiCompiler

MultiCompiler 모듈을 사용하면 webpack이 별도의 컴파일러에서 복수의 설정을 실행할 수 있습니다. webpack NodeJS API에 있는 options 파라미터가 옵션의 배열일 경우, webpack은 별도의 컴파일러를 적용하고 모든 컴파일러가 실행된 후 callback을 호출합니다.

var webpack = require('webpack');

webpack(
  [
    { entry: './index1.js', output: { filename: 'bundle1.js' } },
    { entry: './index2.js', output: { filename: 'bundle2.js' } },
  ],
  (err, stats) => {
    process.stdout.write(stats.toString() + '\n');
  }
);

Error Handling

오류를 잘 처리하려면 다음 세 가지 유형의 오류를 고려해야 합니다.

치명적인 webpack 오류 (잘못된 구성 등)
컴파일 오류 (모듈 누락, 구문 오류 등)
컴파일 경고

다음은 이 모든 작업을 수행하는 예시입니다.

const webpack = require('webpack');

webpack(
  {
    // ...
  },
  (err, stats) => {
    if (err) {
      console.error(err.stack || err);
      if (err.details) {
        console.error(err.details);
      }
      return;
    }

    const info = stats.toJson();

    if (stats.hasErrors()) {
      console.error(info.errors);
    }

    if (stats.hasWarnings()) {
      console.warn(info.warnings);
    }

    // Log result...
  }
);

Custom File Systems

기본적으로 webpack은 파일을 읽고 디스크에 쓰는데 일반 파일 시스템을 사용합니다. 그러나 다른 종류의 파일시스템(메모리, webDAV 등)을 사용하여 입력 또는 출력 동작을 변경할 수 있습니다. 이를 위해 inputFileSystem 또는 outputFileSystem을 변경할 수 있습니다. 예를 들어 기본 outputFileSystem을 memfs으로 변경해서 디스크 대신 메모리에 파일을 쓸 수 있습니다.

const { createFsFromVolume, Volume } = require('memfs');
const webpack = require('webpack');

const fs = createFsFromVolume(new Volume());
const compiler = webpack({
  /* 옵션 */
});

compiler.outputFileSystem = fs;
compiler.run((err, stats) => {
  // 출력 나중에 읽기
  const content = fs.readFileSync('...');
  compiler.close((closeErr) => {
    // ...
  });
});

이것이 webpack-dev-server와 다른 여러 패키지에서 사용하는 webpack-dev-middleware가 파일을 신비하게 숨기면서도 브라우저까지 계속 제공하는 방법입니다!

Stats Data

webpack으로 소스 코드를 컴파일 할 때, 사용자는 모듈에 대한 통계가 포함된 JSON 파일을 생성할 수 있습니다. 이러한 통계는 애플리케이션의 디펜던시 그래프를 분석하고 컴파일 속도를 최적화하는데 사용할 수 있습니다. 파일은 일반적으로 다음 CLI 커맨드로 생성됩니다.

npx webpack --profile --json=compilation-stats.json

--json=compilation-stats.json 플래그는 디펜던시 그래프 및 기타 다양한 빌드 정보가 포함된 compilation-stats.json을 내보내야 함을 webpack에게 나타냅니다. 일반적으로, --profile 플래그도 추가되어 모듈별 컴파일 통계가 포함된 각 modules 객체에 profile 섹션이 추가됩니다.

Structure

출력 JSON 파일의 최상위 구조는 매우 간단하지만 몇 가지 중첩된 데이터 구조도 있습니다. 각 중첩 구조에는 이 문서를 보다 유용하게 사용할 수 있도록 아래에 전용 섹션이 있습니다. 아래의 최상위 구조 내의 링크를 클릭하면 관련 섹션 및 문서로 이동할 수 있습니다.

{
  "version": "5.9.0", // 컴파일에 사용된 webpack 버전
  "hash": "11593e3b3ac85436984a", // 컴파일 특정 해시
  "time": 2469, // 컴파일 시간 밀리초
  "publicPath": "auto",
  "outputPath": "/", // webpack 출력 디렉터리 경로
  "assetsByChunkName": {
    // 내보낸 애셋 매핑에 대한 청크 이름
    "main": ["web.js?h=11593e3b3ac85436984a"],
    "named-chunk": ["named-chunk.web.js"],
    "other-chunk": ["other-chunk.js", "other-chunk.css"]
  },
  "assets": [
    // [애셋 객체](#asset-objects) 목록
  ],
  "chunks": [
    // [청크 객체](#chunk-objects) 목록
  ],
  "modules": [
    // [모듈 객체](#module-objects) 목록
  ],
  "entryPoints": {
    // [엔트리 객체](#entry-objects) 목록
  },
  "errors": [
    // [에러 객체](#errors-and-warnings) 목록
  ],
  "errorsCount": 0, // 오류 개수
  "warnings": [
    // [경고 객체](#errors-and-warnings) 목록
  ],
  "warningsCount": 0 // 경고 개수
}

Asset Objects

각 assets 객체는 컴파일에서 내보낸 output 파일을 나타냅니다. 모두 유사한 구조를 따릅니다.

{
  "chunkNames": [], // 이 애셋에 포함된 청크
  "chunks": [10, 6], // 이 애셋에 포함된 청크 ID
  "comparedForEmit": false, // 애셋이 출력 파일 시스템의 동일한 파일과 비교되었는지 여부
  "emitted": true, // 애셋이 `output` 디렉터리에 도달했는지 여부
  "name": "10.web.js", // `output` 파일 이름
  "size": 1058, // 파일 크기(바이트)
  "info": {
    "immutable": true, // 애셋을 장기간 캐시 할 수 있는지 여부를 나타내는 플래그(해시 포함)
    "size": 1058, // 바이트 단위 크기, 애셋을 내보낸 뒤에만 사용 가능
    "development": true, // 애셋이 개발용으로만 사용되고 사용자 대면 애셋에 포함되지 않는지 여부를 나타내는 플래그
    "hotModuleReplacement": true, // 애셋이 기존 애플리케이션(HMR) 업데이트를 위한 데이터를 제공하는지 여부를 나타내는 플래그
    "sourceFilename": "originalfile.js", // 애셋이 소스 파일에서 생성된 경우의 sourceFilename(변환될 수 있음)
    "javascriptModule": true // true, 애셋이 Javascript 및 EMS인 경우
  }
}

Chunk Objects

각 chunks 객체는 청크로 알려진 모듈 그룹을 나타냅니다. 각 객체는 다음의 구조를 따릅니다.

{
  "entry": true, // 청크에 webpack 런타임이 포함되었는지 여부
  "files": [
    // 이 청크를 포함하는 파일 이름 문자열의 배열
  ],
  "filteredModules": 0, // 위의 [top-level structure](#structure) 설명 참고
  "id": 0, // 이 청크의 ID
  "initial": true, // 이 청크가 초기 페이지 로드 시 로드되는지 아니면 [on demand](/guides/lazy-loading) 시 로드되는지 여부
  "modules": [
    // [모듈 객체](#module-objects) 목록
    "web.js?h=11593e3b3ac85436984a"
  ],
  "names": [
    // 이 청크에 포함된 청크 이름 목록
  ],
  "origins": [
    // 아래 설명 참고...
  ],
  "parents": [], // 상위 청크 ID
  "rendered": true, // 청크가 코드 제너레이션을 거쳤는지 여부
  "size": 188057 // 청크 크기(바이트)
}

chunks 객체에는 주어진 청크가 어떻게 생성되었는지 설명하는 origins 목록도 포함됩니다. 각 origins 객체는 다음 스키마를 따릅니다.

{
  "loc": "", // 이 청크를 생성한 코드 라인
  "module": "(webpack)\\test\\browsertest\\lib\\index.web.js", // 모듈 경로
  "moduleId": 0, // 모듈 ID
  "moduleIdentifier": "(webpack)\\test\\browsertest\\lib\\index.web.js", // 모듈 경로
  "moduleName": "./lib/index.web.js", // 모듈에 대한 상대 경로
  "name": "main", // 청크 이름
  "reasons": [
    // [module objects](#module-objects)에서 찾은 동일한 `reasons` 목록
  ]
}

Module Objects

컴파일된 애플리케이션의 실제 모듈에 대한 설명이 없으면 이런 통계가 무슨 의미가 있겠습니까? 의존성 그래프의 각 모듈은 다음 구조로 표시됩니다.

{
  "assets": [
    // [애셋 객체](#asset-objects) 목록
  ],
  "built": true, // 모듈이 [로더](/concepts/loaders), 파싱 및 코드 제너레이션을 거쳤음을 의미
  "cacheable": true, // 모듈이 캐시 가능한지 여부
  "chunks": [
    // 모듈을 포함하는 청크 ID
  ],
  "errors": 0, // 모듈을 리졸브하거나 처리할 때 발생한 오류 수
  "failed": false, // 모듈에서 컴파일 실패 여부
  "id": 0, // 모듈의 ID ([`module.id`](/api/module-variables/#moduleid-commonjs)와 유사)
  "identifier": "(webpack)\\test\\browsertest\\lib\\index.web.js", // 내부적으로 사용되는 고유 ID
  "name": "./lib/index.web.js", // 실제 파일 경로
  "optional": false, // 모듈에 대한 모든 요청에는 `try... catch` 블록이 있습니다(ESM와 관련 없음)
  "prefetched": false, // 모듈이 [prefetched](/plugins/prefetch-plugin) 되었는지 여부
  "profile": {
    // [`--profile` flag](/api/cli/#profiling)에 해당하는 모듈별 컴파일 통계 (밀리초 단위)
    "building": 73, // 로드 및 파싱
    "dependencies": 242, // 의존성 구축
    "factory": 11 // 의존성 해석
  },
  "reasons": [
    // 아래 설명 참고...
  ],
  "size": 3593, // 모듈 예상 크기(바이트)
  "source": "// Should not break it...\r\nif(typeof...", // 문자열화된 원시 소스
  "warnings": 0 // 모듈을 해석하거나 처리할 때 경고의 수
}

모든 모듈에는 해당 모듈이 의존성 그래프에 포함된 이유를 설명하는 reasons 객체 목록도 포함되어 있습니다. 각 "reason"은 위의 청크 객체 섹션에서 본 origins와 유사합니다.

{
  "loc": "33:24-93", // 모듈을 포함하게 만든 코드의 라인
  "module": "./lib/index.web.js", // [context](/configuration/entry-context/#context) 기반 모듈의 상대 경로
  "moduleId": 0, // 모듈 ID
  "moduleIdentifier": "(webpack)\\test\\browsertest\\lib\\index.web.js", // 모듈 경로
  "moduleName": "./lib/index.web.js", // 모듈의 더 읽기 쉬운 이름 ("pretty-printing"에 사용됨)
  "type": "require.context", // [type of request](/api/module-methods) 사용
  "userRequest": "../../cases" // `import` 또는 `require` 요청에 사용되는 원시 문자열
}

Entry Objects

"main": {
  "name": "main",
  "chunks": [
    179
  ],
  "assets": [
    {
      "name": "main.js",
      "size": 22
    }
  ],
  "filteredAssets": 0,
  "assetsSize": 22,
  "auxiliaryAssets": [],
  "filteredAuxiliaryAssets": 0,
  "auxiliaryAssetsSize": 0,
  "children": {},
  "childAssets": {},
  "isOverSizeLimit": false
}

Errors and Warnings

errors 및 warnings 프로퍼티에는 각각 객체 목록이 포함되어 있습니다. 각 객체에는 메시지, 스택 추적 및 다양한 프로퍼티가 포함되어 있습니다.

{
  "moduleIdentifier": "C:\\Repos\\webpack\\test\\cases\\context\\issue-5750\\index.js",
  "moduleName": "(webpack)/test/cases/context/issue-5750/index.js",
  "loc": "3:8-47",
  "message": "Critical dependency: Contexts can't use RegExps with the 'g' or 'y' flags.",
  "moduleId": 29595,
  "moduleTrace": [
    {
      "originIdentifier": "C:\\Repos\\webpack\\test\\cases|sync|/^\\.\\/[^/]+\\/[^/]+\\/index\\.js$/",
      "originName": "(webpack)/test/cases sync ^\\.\\/[^/]+\\/[^/]+\\/index\\.js$",
      "moduleIdentifier": "C:\\Repos\\webpack\\test\\cases\\context\\issue-5750\\index.js",
      "moduleName": "(webpack)/test/cases/context/issue-5750/index.js",
      "dependencies": [
        {
          "loc": "./context/issue-5750/index.js"
        }
      ],
      "originId": 32582,
      "moduleId": 29595
    },
    {
      "originIdentifier": "C:\\Repos\\webpack\\testCases.js",
      "originName": "(webpack)/testCases.js",
      "moduleIdentifier": "C:\\Repos\\webpack\\test\\cases|sync|/^\\.\\/[^/]+\\/[^/]+\\/index\\.js$/",
      "moduleName": "(webpack)/test/cases sync ^\\.\\/[^/]+\\/[^/]+\\/index\\.js$",
      "dependencies": [
        {
          "loc": "1:0-70"
        }
      ],
      "originId": 8198,
      "moduleId": 32582
    }
  ],
  "details": "at RequireContextDependency.getWarnings (C:\\Repos\\webpack\\lib\\dependencies\\ContextDependency.js:79:5)\n    at Compilation.reportDependencyErrorsAndWarnings (C:\\Repos\\webpack\\lib\\Compilation.js:1727:24)\n    at C:\\Repos\\webpack\\lib\\Compilation.js:1467:10\n    at _next2 (<anonymous>:16:1)\n    at eval (<anonymous>:42:1)\n    at C:\\Repos\\webpack\\node_modules\\neo-async\\async.js:2830:7\n    at Object.each (C:\\Repos\\webpack\\node_modules\\neo-async\\async.js:2850:39)\n    at C:\\Repos\\webpack\\lib\\FlagDependencyExportsPlugin.js:219:18\n    at C:\\Repos\\webpack\\node_modules\\neo-async\\async.js:2830:7\n    at Object.each (C:\\Repos\\webpack\\node_modules\\neo-async\\async.js:2850:39)\n    at C:\\Repos\\webpack\\lib\\FlagDependencyExportsPlugin.js:40:16\n    at Hook.eval [as callAsync] (<anonymous>:38:1)\n    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (C:\\Repos\\tapable\\lib\\Hook.js:18:14)\n    at Compilation.finish (C:\\Repos\\webpack\\lib\\Compilation.js:1462:28)\n    at C:\\Repos\\webpack\\lib\\Compiler.js:909:18\n    at processTicksAndRejections (internal/process/task_queues.js:75:11)\n",
  "stack": "ModuleDependencyWarning: Critical dependency: Contexts can't use RegExps with the 'g' or 'y' flags.\n    at Compilation.reportDependencyErrorsAndWarnings (C:\\Repos\\webpack\\lib\\Compilation.js:1732:23)\n    at C:\\Repos\\webpack\\lib\\Compilation.js:1467:10\n    at _next2 (<anonymous>:16:1)\n    at eval (<anonymous>:42:1)\n    at C:\\Repos\\webpack\\node_modules\\neo-async\\async.js:2830:7\n    at Object.each (C:\\Repos\\webpack\\node_modules\\neo-async\\async.js:2850:39)\n    at C:\\Repos\\webpack\\lib\\FlagDependencyExportsPlugin.js:219:18\n    at C:\\Repos\\webpack\\node_modules\\neo-async\\async.js:2830:7\n    at Object.each (C:\\Repos\\webpack\\node_modules\\neo-async\\async.js:2850:39)\n    at C:\\Repos\\webpack\\lib\\FlagDependencyExportsPlugin.js:40:16\n    at Hook.eval [as callAsync] (<anonymous>:38:1)\n    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (C:\\Repos\\tapable\\lib\\Hook.js:18:14)\n    at Compilation.finish (C:\\Repos\\webpack\\lib\\Compilation.js:1462:28)\n    at C:\\Repos\\webpack\\lib\\Compiler.js:909:18\n    at processTicksAndRejections (internal/process/task_queues.js:75:11)\n"
}

webpack-dev-server API

webpack-dev-server는 Node.js 런타임에서 직접 사용할 수 있는 Node.js API를 제공합니다.

Installation

webpack-dev-server Node.js API를 사용하려면, 먼저 webpack 과 webpack-dev-server를 설치하세요.

npm install --save-dev webpack webpack-dev-server

그런 다음 Node.js 스크립트에 모듈이 필요합니다.

const Webpack = require('webpack');
const WebpackDevServer = require('webpack-dev-server');

start

webpack-dev-server 인스턴스에 서버를 시작하도록 지시합니다.

server.js

const Webpack = require('webpack');
const WebpackDevServer = require('webpack-dev-server');
const webpackConfig = require('./webpack.config.js');

const compiler = Webpack(webpackConfig);
const devServerOptions = { ...webpackConfig.devServer, open: true };
const server = new WebpackDevServer(devServerOptions, compiler);

const runServer = async () => {
  console.log('Starting server...');
  await server.start();
};

runServer();

그런 다음 아래 명령으로 서버를 실행합니다.

node server.js

startCallback(callback)

webpack-dev-server 인스턴스에 서버를 시작한 후 콜백 함수를 실행하도록 지시합니다.

server.js

const Webpack = require('webpack');
const WebpackDevServer = require('webpack-dev-server');
const webpackConfig = require('./webpack.config.js');

const compiler = Webpack(webpackConfig);
const devServerOptions = { ...webpackConfig.devServer, open: true };
const server = new WebpackDevServer(devServerOptions, compiler);

server.startCallback(() => {
  console.log('Successfully started server on http://localhost:8080');
});

그런 다음 아래 명령으로 서버를 실행합니다.

node server.js

stop

webpack-dev-server 인스턴스에 서버를 중지하도록 지시합니다.

server.js

const Webpack = require('webpack');
const WebpackDevServer = require('webpack-dev-server');
const webpackConfig = require('./webpack.config.js');

const compiler = Webpack(webpackConfig);
const devServerOptions = { ...webpackConfig.devServer, open: true };
const server = new WebpackDevServer(devServerOptions, compiler);

const runServer = async () => {
  console.log('Starting server...');
  await server.start();
};

const stopServer = async () => {
  console.log('Stopping server...');
  await server.stop();
};

runServer();

setTimeout(stopServer, 5000);

그런 다음 아래 명령으로 서버를 실행합니다.

node server.js

stopCallback(callback)

webpack-dev-server 인스턴스에 서버를 중지하고 콜백 함수를 실행하도록 지시합니다.

server.js

const Webpack = require('webpack');
const WebpackDevServer = require('webpack-dev-server');
const webpackConfig = require('./webpack.config.js');

const compiler = Webpack(webpackConfig);
const devServerOptions = { ...webpackConfig.devServer, open: true };
const server = new WebpackDevServer(devServerOptions, compiler);

server.startCallback(() => {
  console.log('Successfully started server on http://localhost:8080');
});

const stopServer = () =>
  server.stopCallback(() => {
    console.log('Server stopped.');
  });

setTimeout(stopServer, 5000);

그런 다음 아래 명령으로 서버를 실행합니다.

node server.js

internalIP(family: "v4" | "v6")

내부 IPv4/IPv6 주소를 비동기적으로 반환합니다.

server.js

const WebpackDevServer = require('webpack-dev-server');

const logInternalIPs = async () => {
  const localIPv4 = await WebpackDevServer.internalIP('v4');
  const localIPv6 = await WebpackDevServer.internalIP('v6');

  console.log('Local IPv4 address:', localIPv4);
  console.log('Local IPv6 address:', localIPv6);
};

logInternalIPs();

internalIPSync(family: "v4" | "v6")

내부 IPv4/IPv6 주소를 동기적으로 반환합니다.

server.js

const WebpackDevServer = require('webpack-dev-server');

const localIPv4 = WebpackDevServer.internalIPSync('v4');
const localIPv6 = WebpackDevServer.internalIPSync('v6');

console.log('Local IPv4 address:', localIPv4);
console.log('Local IPv6 address:', localIPv6);

Hot Module Replacement

Hot Module Replacement가 HotModuleReplacementPlugin을 통해 활성화된 경우, 해당 인터페이스는 import.meta.webpackHot프로퍼티 뿐만 아니라 module.hot프로퍼티 아래 노출됩니다. strict ESM에서는 import.meta.webpackHot만 사용할 수 있습니다.

일반적으로, 사용자는 인터페이스에 접근할 수 있는지 확인한 후, 작업을 시작합니다. 예를 들어, 업데이트된 모듈을 accept 하는 방법은 다음과 같습니다.

if (module.hot) {
  module.hot.accept('./library.js', function () {
    // 업데이트된 라이브러리 모듈로 작업을 수행하세요...
  });
}

// or
if (import.meta.webpackHot) {
  import.meta.webpackHot.accept('./library.js', function () {
    // 업데이트된 라이브러리 모듈로 작업을 수행하세요…
  });
}

지원되는 메소드는 다음과 같습니다...

Module API

accept

주어진 dependencies에 대한 업데이트를 수락하고 해당 업데이트에 반응하기 위해 callback을 실행합니다. 또한, 선택적 에러 핸들러를 연결할 수 있습니다.

module.hot.accept(
  dependencies, // 문자열 또는 문자열 배열
  callback, // 의존성이 업데이트될 때 실행할 함수
  errorHandler // (err, {moduleId, dependencyId}) => {}
);

// 또는
import.meta.webpackHot.accept(
  dependencies, // 문자열 또는 문자열 배열
  callback, // 의존성이 업데이트될 때 실행할 함수
  errorHandler // (err, {moduleId, dependencyId}) => {}
);

ESM import를 사용하면 dependencies에서 가져온 모든 심볼이 자동으로 업데이트됩니다. 참고: 의존성 문자열은 import의 from 문자열과 정확히 일치해야 합니다. 경우에 따라 callback을 생략할 수 있습니다. callback에서 require()를 사용하는 것은 여기에서 의미가 없습니다.

CommonJS를 사용할 때 callback에서 require()를 사용해서 의존성을 수동으로 업데이트해야 합니다. callback을 생략하는 경우도 있습니다.

errorHandler for accept

(err, {moduleId, dependencyId}) => {}

err: ESM 의존성을 사용할 때 두 번째 인수 또는 의존성 실행 중에 콜백에 의해 발생한 에러.
moduleId: 현재 모듈 id.
dependencyId: (첫 번째) 변경된 의존성의 모듈 id.

accept (self)

자체적으로 업데이트를 수락합니다.

module.hot.accept(
  errorHandler // 새 버전을 평가할 때 에러를 처리하는 함수
);

// 또는
import.meta.webpackHot.accept(
  errorHandler // 새 버전을 평가할 때 에러를 처리하는 함수
);

모듈 또는 의존성이 업데이트되면, 부모에게 알리지 않고 이 모듈을 폐기하고 재평가 할 수 있습니다. 이것은 이 모듈에 내보내기가 없는 경우(또는 내보내기가 다른 방식으로 업데이트되는 경우) 의미가 있습니다.

이 모듈(또는 의존성)의 평가에서 예외가 발생하면 errorHandler가 실행됩니다.

errorHandler for self accept

(err, {moduleId, module}) => {}

err: 새 버전을 평가할 때 발생한 에러.
moduleId: 현재 모듈 id.
module: 현재 모듈 인스턴스.
- module.hot: 에러가 발생한 모듈 인스턴스의 HMR API를 사용하도록 허용합니다. 일반적인 시나리오는 스스로 그것을 다시 수락하는 것입니다. 또한 데이터를 전달하기 위해 dispose 핸들러를 추가하는 것이 좋습니다. 에러가 발생한 모듈은 이미 부분적으로 실행되었을 수 있음으로, 일관성 없는 상태가 되지 않도록 주의하세요. module.hot.data를 사용하여 부분 상태를 저장할 수 있습니다.
- module.exports: 오버라이드할 수 있지만, 프로덕션 모드에서 프로퍼티 이름이 손상될 수 있음으로 주의하세요.

decline

주어진 dependencies에 대한 업데이트를 거부하여 'decline' 코드로 업데이트가 실패하도록 합니다.

module.hot.decline(
  dependencies // 문자열 또는 문자열 배열
);

// 또는
import.meta.webpackHot.decline(
  dependencies // 문자열 또는 문자열 배열
);

업데이트 불가능으로 의존성에 플래그를 지정합니다. 이것은 의존성 내보내기 변경을 처리할 수 없거나 처리가 아직 구현되지 않은 경우 의미가 있습니다. HMR 관리 코드에 따라, 이러한 의존성(또는 허용되지 않는 의존성)에 대한 업데이트로 인해 일반적으로 전체 페이지가 다시 로드됩니다.

decline (self)

자체적으로 업데이트를 거부합니다.

module.hot.decline();

// 또는
import.meta.webpackHot.decline();

업데이트 불가능으로 모듈에 플래그를 지정합니다. 이는 이 모듈에 되돌릴 수 없는 사이드 이펙트가 있거나, 이 모듈에 대해 HMR 처리가 아직 구현되지 않은 경우 의미가 있습니다. HMR 관리 코드에 따라, 이러한 모듈(또는 허용되지 않은 의존성)에 대한 업데이트로 인해 일반적으로 전체 페이지가 다시 로드됩니다.

dispose (or addDisposeHandler)

현재 모듈 코드가 교체될 때 실행되는 핸들러를 추가합니다. 이것은 요청하거나 생성한 영구 리소스를 제거하는 데 사용해야 합니다. 업데이트된 모듈에 상태를 전송하려면, 주어진 data 파라미터에 추가하세요. 이 객체는 업데이트 후 module.hot.data에서 사용할 수 있습니다.

module.hot.dispose((data) => {
  // 데이터를 정리하고 업데이트된 모듈로 전달합니다.
});

// 또는
import.meta.webpackHot.dispose((data) => {
  // 데이터를 정리하고 업데이트된 모듈로 전달합니다.
});

invalidate

이 메서드를 호출하면 현재 모듈이 무효화 되고, HMR 업데이트가 적용될 때 이를 삭제하고 다시 생성합니다. 버블은 이 모듈의 일반 업데이트와 같습니다. 이 모듈은 invalidate를 자체 승인할 수 없습니다.

idle 상태에서 호출되면, 이 모듈을 포함하는 새 HMR 업데이트가 생성됩니다. HMR은 ready 상태로 들어갑니다.

ready 또는 prepare 상태에서 호출되면, 이 모듈은 현재 HMR 업데이트에 추가됩니다.

check 상태에서 호출되면, 이 모듈은 업데이트를 사용할 수 있을 때 업데이트에 추가됩니다. 사용 가능한 업데이트가 없으면 새 업데이트가 생성됩니다. HMR은 ready 상태로 들어갑니다.

dispose 또는 apply 상태에서 호출되면, HMR은 해당 상태에서 나온 후 이를 선택합니다.

Use Cases

Conditional Accepting

모듈은 의존성을 받아들일 수 있지만, 의존성 변경을 처리할 수 없는 경우 invalidate를 호출할 수 있습니다.

import { x, y } from './dep';
import { processX, processY } from 'anotherDep';

const oldY = y;

processX(x);
export default processY(y);

module.hot.accept('./dep', () => {
  if (y !== oldY) {
    // 처리할 수 없으며, 부모에게 전달
    module.hot.invalidate();
    return;
  }
  // 처리할 수 없음
  processX(x);
});

Conditional self accept

모듈은 자체 수용할 수 있지만, 변경 사항을 처리할 수 없을 때 자체를 무효화 할 수 있습니다.

const VALUE = 'constant';

export default VALUE;

if (
  module.hot.data &&
  module.hot.data.value &&
  module.hot.data.value !== VALUE
) {
  module.hot.invalidate();
} else {
  module.hot.dispose((data) => {
    data.value = VALUE;
  });
  module.hot.accept();
}

Triggering custom HMR updates

const moduleId = chooseAModule();
const code = __webpack_modules__[moduleId].toString();
__webpack_modules__[moduleId] = eval(`(${makeChanges(code)})`);
if (require.cache[moduleId]) {
  require.cache[moduleId].hot.invalidate();
  module.hot.apply();
}

removeDisposeHandler

dispose 또는 addDisposeHandler를 통해 추가된 핸들러를 제거합니다.

module.hot.removeDisposeHandler(callback);

// 또는
import.meta.webpackHot.removeDisposeHandler(callback);

Management API

status

hot module replacement 프로세스의 현재 상태를 검색합니다.

module.hot.status(); // 다음 문자열 중 하나를 반환합니다...

// 또는
import.meta.webpackHot.status();

Status	Description
idle	프로세스가 `check` 호출을 기다리고 있습니다
check	프로세스가 업데이트를 확인하는 중입니다
prepare	프로세스가 업데이트를 준비 중입니다 (예. 업데이트된 모듈 다운로드)
ready	업데이트가 준비되어 사용 가능합니다
dispose	프로세스는 교체될 모듈에서 `dispose` 핸들러를 호출합니다
apply	프로세스가 `accept` 핸들러를 호출하고 자체 승인된 모듈을 다시 실행합니다
abort	업데이트가 중단되었지만, 시스템은 여전히 이전 상태입니다
fail	업데이트에서 예외가 발생했으며 시스템 상태가 손상되었습니다

check

업데이트를 위해 로드된 모든 모듈을 테스트하고, 업데이트가 있는 경우 이를 apply 합니다.

module.hot
  .check(autoApply)
  .then((outdatedModules) => {
    // outdated 모듈...
  })
  .catch((error) => {
    // 에러 catch
  });

// 또는
import.meta.webpackHot
  .check(autoApply)
  .then((outdatedModules) => {
    // outdated 모듈...
  })
  .catch((error) => {
    // 에러 catch
  });

autoApply 파라미터는 boolean이거나 호출될 때 apply메서드에 전달할 options일 수 있습니다.

apply

업데이트 프로세스를 계속합니다.(module.hot.status() === 'ready'인 동안)

module.hot
  .apply(options)
  .then((outdatedModules) => {
    // outdated 모듈...
  })
  .catch((error) => {
    // 에러 catch
  });

// 또는
import.meta.webpackHot
  .apply(options)
  .then((outdatedModules) => {
    // outdated 모듈...
  })
  .catch((error) => {
    // 에러 catch
  });

선택적 options 객체에는 다음 프로퍼티가 포함될 수 있습니다.

ignoreUnaccepted (boolean): 허용되지 않는 모듈에 대한 변경 사항을 무시합니다.
ignoreDeclined (boolean): 거부된 모듈에 대한 변경 사항을 무시합니다.
ignoreErrored (boolean): accept 핸들러, 에러 핸들러 및 모듈을 재평가하는 동안 발생하는 에러를 무시합니다.
onDeclined (function(info)): 거부된 모듈에 대한 알림
onUnaccepted (function(info)): 허용되지 않는 모듈에 대한 알림
onAccepted (function(info)): 허용된 모듈에 대한 알림
onDisposed (function(info)): 폐기된 모듈에 대한 알림
onErrored (function(info)): 에러 알림

info 파라미터는 다음 값 중 일부를 포함하는 객체입니다.

{
  type: 'self-declined' | 'declined' |
        'unaccepted' | 'accepted' |
        'disposed' | 'accept-errored' |
        'self-accept-errored' | 'self-accept-error-handler-errored',
  moduleId: 4, // 질문의 모듈.
  dependencyId: 3, // 에러의 경우: accept 핸들러를 소유한 모듈 id.
  chain: [1, 2, 3, 4], // 거부/허용/허용되지 않음의 경우: 업데이트가 전파된 체인.
  parentId: 5, // 거부된 경우: 거부하는 상위의 모듈 ic
  outdatedModules: [1, 2, 3, 4], // 허용된 경우: 오래되어 폐기될 모듈
  outdatedDependencies: { // 허용된 경우: 업데이트를 처리할 accept 핸들러의 위치
    5: [4]
  },
  error: new Error(...), // 에러의 경우: throw 된 에러
  originalError: new Error(...) // For self-accept-error-handler-errored:
                                // 에러 핸들러가 처리를 시도하기 전에 모듈에서 발생한 에러.
}

addStatusHandler

status의 변경을 수신할 함수 등록합니다.

module.hot.addStatusHandler((status) => {
  // 현재 상태에 반응...
});

// 또는
import.meta.webpackHot.addStatusHandler((status) => {
  // 현재 상태에 반응...
});

상태 핸들러가 Promise를 반환하면, HMR 시스템은 계속하기 전에 Promise가 해결될 때까지 기다립니다.

removeStatusHandler

등록된 상태 핸들러 제거.

module.hot.removeStatusHandler(callback);

// 또는
import.meta.webpackHot.removeStatusHandler(callback);

Loader Interface

로더는 함수를 내보내는 자바스크립트 모듈입니다. 로드 러너는 이 함수를 호출하여 이전 로더 혹은 리소스 파일의 결과를 전달합니다. 함수의 this 컨텍스트는 webpack과 로드 러너에 의해 채워지며, 로더가 호출스타일을 비동기로 변경하거나 쿼리 매개변수를 가져올 수 있도록 하는 몇가지 유용한 메소드를 제공합니다.

첫 번째 로더에는 리소스 파일의 내용이라는 하나의 인수를 넘깁니다. 컴파일러는 마지막 로더의 결과를 기대합니다. 결과는 모듈의 자바스크립트 소스 코드를 나타내는 String 또는 Buffer(문자열로 변환됨)여야 합니다. 선택적 소스맵 결과(JSON 객체로)도 전달할 수 있습니다.

단일 결과는 동기 모드에서 반환될 수 있습니다. 여러 결과의 경우 this.callback()을 호출해야 합니다. 비동기 모드에서는 로드 러너가 비동기 결과를 기다려야 함을 나타내기 위해 this.async()를 호출해야 합니다. 이는 this.callback()을 반환합니다. 그 후 로더는 undefined를 반환하고 해당 콜백을 호출해야 합니다.

/**
 *
 * @param {string|Buffer} [content] 리소스 파일의 내용
 * @param {object} [map] https://github.com/mozilla/source-map 에서 사용할 수 있는 소스맵 데이터
 * @param {any} [meta] 메타 데이터, 무엇이든 될 수 있습니다
 */
function webpackLoader(content, map, meta) {
  // webpack 로더의 코드
}

Examples

다음 섹션에서는 다양한 유형의 로더에 대한 몇 가지 기본 예를 제공합니다. map 및 meta 매개변수는 선택 사항입니다. 아래의 this.callback을 참고하세요.

Synchronous Loaders

return 또는 this.callback을 사용하여 변환된 content를 동기적으로 반환할 수 있습니다.

sync-loader.js

module.exports = function (content, map, meta) {
  return someSyncOperation(content);
};

this.callback 메소드는 content만 사용하는 것이 아니라 여러 인수를 전달할 수 있으므로 더 유연합니다.

sync-loader-with-multiple-results.js

module.exports = function (content, map, meta) {
  this.callback(null, someSyncOperation(content), map, meta);
  return; // callback() 함수를 호출하면 항상 undefined를 반환합니다.
};

Asynchronous Loaders

비동기 로더의 경우 this.async는 callback 함수를 가져오기 위해 사용됩니다.

async-loader.js

module.exports = function (content, map, meta) {
  var callback = this.async();
  someAsyncOperation(content, function (err, result) {
    if (err) return callback(err);
    callback(null, result, map, meta);
  });
};

async-loader-with-multiple-results.js

module.exports = function (content, map, meta) {
  var callback = this.async();
  someAsyncOperation(content, function (err, result, sourceMaps, meta) {
    if (err) return callback(err);
    callback(null, result, sourceMaps, meta);
  });
};

"Raw" Loader

기본적으로 리소스 파일은 UTF-8 문자열로 변환되어 로더에 전달됩니다. raw 플래그를 true로 설정하면 로더가 원시 Buffer를 받게 됩니다. 모든 로더는 결과를 String 혹은 Buffer로 전달할 수 있습니다. 컴파일러는 로더 사이에서 변환되어 작동됩니다.

raw-loader.js

module.exports = function (content) {
  assert(content instanceof Buffer);
  return someSyncOperation(content);
  // 반환 값도 `Buffer`가 될 수 있습니다.
  // 로더가 "raw"가 아닌 경우에도 허용됩니다.
};
module.exports.raw = true;

Pitching Loader

로더는 항상 오른쪽에서 왼쪽으로 호출됩니다. 로더가 요청 뒤의 메타 데이터에만 관심을 두고 이전 로더의 결과를 무시할 수 있는 경우가 있습니다. 로더의 pitch 메소드는 로더가 실제로 실행(오른쪽에서 왼쪽으로)되기 전에 왼쪽에서 오른쪽으로 호출됩니다.

다음과 같은 use 설정을 살펴보겠습니다.

module.exports = {
  //...
  module: {
    rules: [
      {
        //...
        use: ['a-loader', 'b-loader', 'c-loader'],
      },
    ],
  },
};

다음 단계들이 발생합니다.

|- a-loader `pitch`
  |- b-loader `pitch`
    |- c-loader `pitch`
      |- 요청된 모듈이 의존성으로 선택됩니다
    |- c-loader 정상 실행
  |- b-loader 정상 실행
|- a-loader 정상 실행

그렇다면 로더가 "pitching" 단계를 이용하는 이유는 무엇일까요?

첫째, pitch 메소드에 전달된 data는 실행 단계에서도 this.data 아래에 노출되며 실행 주기의 초기부터 정보를 캡처하고 공유하는 데 유용할 수 있습니다.

module.exports = function (content) {
  return someSyncOperation(content, this.data.value);
};

module.exports.pitch = function (remainingRequest, precedingRequest, data) {
  data.value = 42;
};

둘째, 로더가 pitch 방식으로 결과를 전달하면 프로세스가 돌아가 나머지 로더를 건너뜁니다. 아래는 위의 예시에서 b-loader의 pitch 메소드가 무언가를 반환했을 때의 경우를 살펴봅니다.

module.exports = function (content) {
  return someSyncOperation(content);
};

module.exports.pitch = function (remainingRequest, precedingRequest, data) {
  if (someCondition()) {
    return (
      'module.exports = require(' +
      JSON.stringify('-!' + remainingRequest) +
      ');'
    );
  }
};

위의 단계는 다음과 같이 단축됩니다.

|- a-loader `pitch`
  |- b-loader는 `pitch`를 통해 모듈을 리턴합니다
|- a-loader 정상 실행

The Loader Context

로더 컨텍스트는 this 속성에 할당된 로더 내부에서 사용할 수 있는 속성을 나타냅니다.

Example for the loader context

다음 예제가 주어지면 require 호출이 사용됩니다.

/abc/file.js의 경우

require('./loader1?xyz!loader2!./resource?rrr');

this.addContextDependency

addContextDependency(directory: string)

로더 결과의 의존성으로 디렉터리를 추가합니다.

this.addDependency

addDependency(file: string)
dependency(file: string) // 단축

기존 파일을 감시할 수 있게 만들기 위해 로더 결과의 의존성으로 파일을 추가합니다. 예를 들어, sass-loader, less-loader는 가져온 css 파일이 변경될 때마다 이를 사용하여 재컴파일합니다.

this.addMissingDependency

addMissingDependency(file: string)

존재하지 않는 파일을 감시할 수 있게 만들기 위해 로더 결과의 의존성으로 파일을 추가합니다. addDependency와 유사하지만 감시자가 올바르게 연결되기 전에 컴파일하는 동안 파일 생성을 처리합니다.

this.async

로더가 비동기로 콜백할 예정임을 loader-runner에 알립니다. this.callback을 반환합니다.

this.cacheable

아래는 캐시 가능 여부를 플래그로 설정하는 함수입니다.

cacheable(flag = true: boolean)

기본적으로 로더 결과는 캐시 가능한 것으로 플래그가 지정됩니다. 로더의 결과를 캐시할 수 없도록 하려면 false를 전달해 이 메소드를 호출하세요.

캐시 가능한 로더는 입력과 의존성이 변경되지 않는 한 변하지 않는 결과를 가져야 합니다. 이는 로더가 this.addDependency로 지정된 것 이외의 의존성을 갖지 않아야 함을 의미합니다.

this.callback

여러 결과를 반환하기 위해 동기식 또는 비동기식으로 호출할 수 있는 함수입니다. 예상되는 인수는 다음과 같습니다.

this.callback(
  err: Error | null,
  content: string | Buffer,
  sourceMap?: SourceMap,
  meta?: any
);

첫 번째 인수는 반드시 Error 또는 null이어야 합니다.
두 번째 인수는 string 또는 Buffer입니다.
세 번째 인수는 선택적입니다. 세 번째 인수는 이 모듈로 파싱될 수 있는 소스맵이어야 합니다.
네 번째 인수도 선택적입니다. webpack이 무시하는 네 번째 옵션은 무엇이든 될 수 있습니다.(예: 일부 메타 데이터)

이 함수가 호출되는 경우 로더의 모호한 결과를 피하고자 undefined를 반환해야 합니다.

this.clearDependencies

clearDependencies();

로더 결과의 모든 의존성을 제거합니다. 이는 초기 의존성과 다른 로더의 의존성을 포함합니다. pitch 사용을 고려하세요.

this.context

모듈의 디렉터리. 다른 것을 해석하기 위한 컨텍스트로 사용할 수 있습니다.

이 예제에서 resource.js가 이 디렉터리에 있기 때문에 /abc가 됩니다.

this.data

로더의 pitch와 정상 실행 단계 간에 공유되는 데이터 객체입니다.

this.emitError

emitError(error: Error)

출력에도 표시될 수 있는 오류를 내보냅니다.

ERROR in ./src/lib.js (./src/loader.js!./src/lib.js)
Module Error (from ./src/loader.js):
Here is an Error!
 @ ./src/index.js 1:0-25

this.emitFile

emitFile(name: string, content: Buffer|string, sourceMap: {...})

파일을 내보냅니다. 이는 webpack에 따라 다릅니다.

this.emitWarning

emitWarning(warning: Error)

다음과 같이 출력에 표시될 경고를 내보냅니다.

WARNING in ./src/lib.js (./src/loader.js!./src/lib.js)
Module Warning (from ./src/loader.js):
Here is a Warning!
 @ ./src/index.js 1:0-25

this.environment

생성된 런타임 코드에서 어떤 종류의 ES 기능을 사용할 수 있는지 확인하세요.

예시:

{
  // 화살표 함수('() => { ... }')를 지원합니다.
  "arrowFunction": true,
  // BigInt를 문자 그대로 지원합니다(예를 들어, 123n).
  "bigIntLiteral": false,
  // const 및 let 변수 선언을 지원합니다.
  "const": true,
  // destructuring을 지원합니다('{ a, b } = obj' 처럼 사용합니다).
  "destructuring": true,
  // EcmaScript 모듈을 가져오는 비동기 import() 함수를 지원합니다.
  "dynamicImport": false,
  // 현재 웹 대상에 대해서만 작업자를 만들 때 async import()를 지원합니다.
  "dynamicImportInWorker": false,
  // 'for of' 반복자를 지원합니다('for (const x of array) { ... }' 처럼 사용합니다).
  "forOf": true,
  // 'globalThis'를 지원합니다.
  "globalThis": true,
  // ECMAScript 모듈을 가져오는 ECMAScript Module syntax를 지원합니다(import ... from '...' 처럼 사용합니다).
  "module": false,
  // 옵셔널 체이닝('obj?.a' 또는 'obj?.()')을 지원합니다.
  "optionalChaining": true,
  // 템플릿 리터럴을 지원합니다.
  "templateLiteral": true
}

this.fs

compilation의 inputFileSystem 속성에 접근합니다.

this.getOptions(schema)

주어진 로더 옵션을 추출합니다. 선택적으로 JSON 스키마를 인수로 허용합니다.

this.getResolve

getResolve(options: ResolveOptions): resolve

resolve(context: string, request: string, callback: function(err, result: string))
resolve(context: string, request: string): Promise<string>

this.resolve와 유사한 resolve 함수를 만듭니다.

Webpack resolve 옵션 아래의 모든 옵션이 가능합니다. 설정된 resolve 옵션과 병합됩니다. "..."는 resolve 옵션에서 값을 확장하기 위해 배열에서 사용할 수 있습니다(예: { extensions: [".sass", "..."] }).

options.dependencyType은 추가 옵션입니다. 이는 우리가 resolve 옵션에서 byDependency를 해석하는 데 사용되는 의존성 타입을 지정할 수 있도록 합니다.

해석 작업의 모든 의존성은 현재 모듈에 대한 의존성으로 자동 추가됩니다.

this.hot

로더용 HMR에 대한 정보입니다.

module.exports = function (source) {
  console.log(this.hot); // --hot 플래그 또는 webpack 설정을 통해 HMR이 활성화된 경우 true입니다.
  return source;
};

this.hashDigest

string

5.95.0+

해시를 생성할 때 사용할 인코딩입니다. output.hashDigest를 참고하세요.

this.hashDigestLength

number

5.95.0+

사용할 해시 다이제스트의 접두사 길이입니다. output.hashDigestLength를 참고하세요.

this.hashFunction

string function

5.95.0+

사용할 해싱 알고리즘입니다. output.hashFunction을 참고하세요.

this.hashSalt

string

5.95.0+

Node.JS의 hash.update를 통해 해시를 업데이트하는 선택적 salt입니다. output.hashSalt를 참고하세요.

this.importModule

5.32.0+

this.importModule(request, options, [callback]): Promise

자식 컴파일러가 빌드 시 요청을 컴파일하고 실행하기 위한 대체 경량 솔루션입니다.

request: 모듈을 로드할 요청 문자열입니다
options:
- layer: 이 모듈이 배치/컴파일되는 레이어를 지정합니다
- publicPath: 빌드된 모듈에 사용되는 공개 경로입니다
callback: 모듈의 export 또는 ESM용 네임스페이스 객체를 리턴하는 Node.js 스타일의 선택적 콜백 함수입니다. 콜백을 제공하지 않으면 importModule이 Promise를 리턴합니다.

webpack.config.js

module.exports = {
  module: {
    rules: [
      {
        test: /stylesheet\.js$/i,
        use: ['./a-pitching-loader.js'],
        type: 'asset/source', // 로더가 문자열을 리턴하므로 타입을 'asset/source'로 설정합니다
      },
    ],
  },
};

a-pitching-loader.js

exports.pitch = async function (remaining) {
  const result = await this.importModule(
    this.resourcePath + '.webpack[javascript/auto]' + '!=!' + remaining
  );
  return result.default || result;
};

src/stylesheet.js

import { green, red } from './colors.js';
export default `body { background: ${red}; color: ${green}; }`;

src/colors.js

export const red = '#f00';
export const green = '#0f0';

src/index.js

import stylesheet from './stylesheet.js';
// 스타일 시트는 빌드시 문자열 `body { background: #f00; color: #0f0; }`가 됩니다

위 예에서 다음과 같은 사실을 알 수 있습니다

pitching 로더가 존재합니다
해당 pitching 로더에서 !=! 구문을 사용하여 요청에 대한 matchResource를 설정합니다. 즉, 원본 리소스 대신 module.rules와 일치시키기 위해 this.resourcePath + '.webpack[javascript/auto]'를 사용합니다.
.webpack[javascript/auto]는 .webpack[type] 패턴의 유사 확장이며, 다른 모듈 타입이 지정되지 않은 경우 기본 모듈 타입을 지정하는 데 사용합니다. 일반적으로 !=! 구문과 함께 사용됩니다.

위의 예는 단순화된 예제이므로 webpack 저장소에서 전체 예제를 확인할 수 있습니다.

this.loaderIndex

현재 로더의 로더 배열에 있는 인덱스입니다.

예제에서 loader1은 0, loader2은 1입니다.

this.loadModule

loadModule(request: string, callback: function(err, source, sourceMap, module))

모듈에 대한 주어진 요청을 해석하고 설정된 모든 로더를 적용하고 생성된 소스, 소스맵 및 모듈 인스턴스(일반적으로 NormalModule의 인스턴스)로 콜백합니다. 결과를 생성하기 위해 다른 모듈의 소스 코드를 알아야 하는 경우 이 기능을 사용합니다.

로더 컨텍스트의 this.loadModule은 기본적으로 CommonJS 해석 규칙을 사용합니다. 'esm', 'commonjs' 또는 사용자 정의와 같은 다른 해석을 사용하기 전에 적절한 dependencyType과 함께 this.getResolve를 사용하세요.

this.loaders

모든 로더의 배열입니다. pitch 단계에서 쓸 수 있습니다.

loaders = [{request: string, path: string, query: string, module: function}]

예제의 내용입니다.

[
  {
    request: '/abc/loader1.js?xyz',
    path: '/abc/loader1.js',
    query: '?xyz',
    module: [Function],
  },
  {
    request: '/abc/node_modules/loader2/index.js',
    path: '/abc/node_modules/loader2/index.js',
    query: '',
    module: [Function],
  },
];

this.mode

어떤 mode webpack이 실행되고 있는지 읽습니다.

가능한 값은 'production', 'development', 'none'입니다.

this.query

로더가 options 객체로 설정된 경우 해당 객체를 가리킵니다.
로더에 options이 없지만 쿼리 문자열로 호출된 경우 ?로 시작하는 문자열이 됩니다.

this.request

해석된 요청 문자열입니다.

예제의 '/abc/loader1.js?xyz!/abc/node_modules/loader2/index.js!/abc/resource.js?rrr'

this.resolve

resolve(context: string, request: string, callback: function(err, result: string))

require 표현식과 같은 요청을 resolve(해석)합니다.

context는 디렉터리의 절대 경로여야 합니다. 이 디렉터리는 해석을 위한 시작 위치로 사용됩니다.
request는 해석될 요청입니다. 일반적으로 ./relative와 같은 상대 요청이나 module/path와 같은 모듈이 요청되지만 /some/path와 같은 절대 경로도 요청으로 가능합니다.
callback은 resolve된 경로를 제공하는 일반 Node.js 스타일 콜백 함수입니다.

resolve 작업의 모든 의존성은 현재 모듈에 대한 의존성으로 자동 추가됩니다.

this.resource

쿼리를 포함한 요청의 리소스 부분입니다.

예제의 '/abc/resource.js?rrr'

this.resourcePath

리소스 파일입니다.

예제의 '/abc/resource.js'

this.resourceQuery

리소스의 쿼리입니다.

예제의 '?rrr'

this.rootContext

Webpack 4부터 기존의 this.options.context는 this.rootContext로 제공됩니다.

this.sourceMap

소스맵을 생성해야 하는지 여부를 알려줍니다. 소스맵을 생성하는 것은 비용이 많이 드는 작업이므로 소스맵이 실제로 요청되었는지 확인해야 합니다.

this.target

컴파일 대상입니다. 설정 옵션에서 전달됩니다.

예: 'web', 'node'

this.utils

5.27.0+

다음 유틸리티에 접근합니다.

absolutify: 가능한 경우 절대 경로를 사용하여 새 요청 문자열을 리턴합니다.
contextify: 가능한 경우 절대 경로를 피하는 새 요청 문자열을 리턴합니다.
createHash: 제공된 해시 함수에서 새 Hash 객체를 반환합니다.

my-sync-loader.js

module.exports = function (content) {
  this.utils.contextify(
    this.context,
    this.utils.absolutify(this.context, './index.js')
  );
  this.utils.absolutify(this.context, this.resourcePath);
  const mainHash = this.utils.createHash(
    this._compilation.outputOptions.hashFunction
  );
  mainHash.update(content);
  mainHash.digest('hex');
  // …
  return content;
};

this.version

로더 API 버전입니다. 현재는 2버전입니다. 이는 이전 버전과의 호환성을 제공하는 데 유용합니다. 버전을 사용하여 커스텀 동작 또는 주요 변경 사항에 대한 대체를 지정할 수 있습니다.

this.webpack

이 boolean은 webpack에 의해 컴파일될 때 true로 설정됩니다.

Webpack specific properties

로더 인터페이스는 모든 모듈 관련 정보를 제공합니다. 그러나 드문 경우로 컴파일러 API 자체에 접근해야 할 수도 있습니다.

그러므로 최후의 수단으로만 사용해야 합니다. 이 속성들을 사용하면 로더의 범용성이 떨어집니다.

this._compilation

Webpack의 현재 Compilation 객체에 접근합니다.

this._compiler

Webpack의 현재 Compiler 객체에 접근합니다.

Deprecated context properties

this.debug

Boolean 플래그입니다. 디버그 모드일 때 설정됩니다.

this.inputValue

마지막 로더에서 전달되었습니다. 입력 인수를 모듈로 실행하려는 경우 이 변수를 바로가기(성능용)로 읽는 것을 고려하세요.

this.minimize

결과가 최소화 되어야 하는지 여부를 알려줍니다.

this.value

다음 로더에 값을 전달합니다. 모듈로 실행했을 때 결과가 무엇을 내보내는지 알고 있다면 여기에서 이 값을 설정(유일한 배열 요소로)하십시오.

this._module

로드되는 모듈 객체에 대한 hacky 접근.

Error Reporting

다음을 통해 로더 내부에서 오류를 보고할 수 있습니다.

this.emitError를 사용합니다. 모듈의 컴파일을 중단하지 않고 오류를 보고합니다.
throw(혹은 기타 잡히지 않는 예외)를 사용합니다. 로더가 실행되는 동안 오류가 발생하면 현재 모듈 컴파일이 실패합니다.
callback(비동기 모드에서)를 사용합니다. 콜백에 오류를 전달하면 모듈 컴파일 실패도 발생합니다.

예시:

./src/index.js

require('./loader!./lib');

로더에서 오류가 발생하는 경우입니다.

./src/loader.js

module.exports = function (source) {
  throw new Error('This is a Fatal Error!');
};

또는 비동기 모드에서 콜백에 오류를 전달하는 경우입니다.

./src/loader.js

module.exports = function (source) {
  const callback = this.async();
  //...
  callback(new Error('This is a Fatal Error!'), source);
};

모듈은 다음과 같이 번들로 제공됩니다.

/***/ "./src/loader.js!./src/lib.js":
/*!************************************!*\
  !*** ./src/loader.js!./src/lib.js ***!
  \************************************/
/*! no static exports found */
/***/ (function(module, exports) {

throw new Error("Module build failed (from ./src/loader.js):\nError: This is a Fatal Error!\n    at Object.module.exports (/workspace/src/loader.js:3:9)");

/***/ })

그후 다음 빌드 출력에도 오류가 표시됩니다(this.emitError와 유사합니다).

ERROR in ./src/lib.js (./src/loader.js!./src/lib.js)
Module build failed (from ./src/loader.js):
Error: This is a Fatal Error!
    at Object.module.exports (/workspace/src/loader.js:2:9)
 @ ./src/index.js 1:0-25

아래에서 볼 수 있듯이 오류 메시지뿐만 아니라 관련 로더 및 모듈에 대한 세부 정보도 표시됩니다.

모듈 경로: ERROR in ./src/lib.js
요청 문자열: (./src/loader.js!./src/lib.js)
로더 경로: (from ./src/loader.js)
호출자 경로: @ ./src/index.js 1:0-25

Inline matchResource

새로운 인라인 요청 구문이 webpack v4에 도입되었습니다. 요청에 접두사 <match-resource>!=!를 붙이면 이 요청에 대한 matchResource가 설정됩니다.

matchResource가 설정되면 원래 리소스 대신 module.rules와 일치하는 데 사용됩니다. 이는 리소스에 추가 로더를 적용해야 하거나 모듈 유형을 변경해야 하는 경우에 유용할 수 있습니다. 또한 통계에 표시되며 splitChunks에서 test와 Rule.issuer를 일치시키는 데 사용됩니다.

예제:

file.js

/* STYLE: body { background: red; } */
console.log('yep');

로더는 파일을 다음 파일로 변환하고 matchResource를 사용하여 사용자 지정 CSS 처리 규칙을 적용할 수 있습니다.

file.js (로더에 의해 변환되었습니다)

import './file.js.css!=!extract-style-loader/getStyles!./file.js';
console.log('yep');

이는 extract-style-loader/getStyles!./file.js에 종속성을 추가하고 결과를 file.js.css로 처리합니다. module.rules에는 /\.css$/와 일치하는 규칙이 있고 이 종속성에 적용되기 때문입니다.

로더는 다음과 같이 보일 수 있습니다.

extract-style-loader/index.js

const getStylesLoader = require.resolve('./getStyles');

module.exports = function (source) {
  if (STYLES_REGEXP.test(source)) {
    source = source.replace(STYLES_REGEXP, '');
    return `import ${JSON.stringify(
      this.utils.contextify(
        this.context || this.rootContext,
        `${this.resource}.css!=!${getStylesLoader}!${this.remainingRequest}`
      )
    )};${source}`;
  }
  return source;
};

extract-style-loader/getStyles.js

module.exports = function (source) {
  const match = source.match(STYLES_REGEXP);
  return match[0];
};

Logging

로깅 API는 webpack 4.37 릴리즈부터 사용할 수 있습니다. stats 설정에서 logging이 활성화되거나 infrastructure 로깅이 활성화되면 로더가 메세지를 기록할 수 있으며 이 메세지는 해당 로거 형식(stats, infrastructure)으로 출력됩니다.

로더는 this.getLogger()를 사용하는 것을 선호해야 합니다. 이는 로더 경로와 처리된 파일을 포함한 compilation.getLogger()의 단축어입니다. 이러한 종류의 로깅은 stats에 저장되고 그에 따라 형식이 지정됩니다. webpack 사용자가 필터링하고 내보낼 수 있습니다.
로더는 this.getLogger('name')를 사용하여 자식 이름을 가진 독립 로거를 얻을 수 있습니다. 로더 경로 및 처리된 파일은 계속 추가됩니다.
로더는 getLogger 방식을 지원하지 않는 이전 webpack 버전이 사용되는 경우 대체 코드를 제공하기 위해 this.getLogger ? this.getLogger() : console를 감지하는 특정한 대체 코드를 사용할 수 있습니다.

Logger Interface

로깅 출력은 최종 사용자에게 메시지를 표시하는 추가적인 방법입니다.

webpack애서 사용자 정의 로깅 API의 이점:

로깅 설정 표시 레벨의 공통 위치
stats.json의 일부로 export 할 수 있는 로깅 출력입니다.
통계 프리셋은 로깅 출력에 영향을 줍니다.
플러그인이 로깅 캡처 및 표시 레벨에 영향을 줄 수 있습니다.
여러 플러그인 및 로더를 사용하는 경우 공통 로깅 솔루션을 사용합니다.
CLI, webpack용 UI 도구는 로깅을 표시하는 다른 방법을 선택할 수 있습니다.
webpack 코어는 로깅 출력을 내보낼 수 있습니다. 예) 타이밍 데이터

webpack 로깅 API를 도입함으로써 webpack 플러그인 및 로더가 로그를 내보내는 방식을 통합하고 빌드 문제를 검사하는 더 나은 방법을 제공하기를 바랍니다. 통합 로깅 솔루션은 개발 경험을 개선하여 플러그인 및 로더 개발자를 지원합니다. 대시보드 또는 기타 UI와 같은 CLI가 아닌 wepack 솔루션을 위한 기반을 마련합니다.

Examples of how to get and use webpack logger in loaders and plugins

my-webpack-plugin.js

const PLUGIN_NAME = 'my-webpack-plugin';
export class MyWebpackPlugin {
  apply(compiler) {
    // 컴파일러에서 로거에 액세스 할 수 있습니다.
    const logger = compiler.getInfrastructureLogger(PLUGIN_NAME);
    logger.log('log from compiler');

    compiler.hooks.compilation.tap(PLUGIN_NAME, (compilation) => {
      // 컴파일에서도 로거에 액세스 할 수 있습니다.
      const logger = compilation.getLogger(PLUGIN_NAME);
      logger.info('log from compilation');
    });
  }
}

my-webpack-loader.js

module.exports = function (source) {
  // webpack 로더에서 `this.getLogger`로 로거를 얻을 수 있습니다.
  const logger = this.getLogger('my-webpack-loader');
  logger.info('hello Logger');
  return source;
};

위의 my-webpack-plugin.js 예제에서 볼 수 있듯이, 두 가지 유형의 로깅 방법이 있습니다.

compilation.getLogger
compiler.getInfrastructureLogger

플러그인/로깅이 컴파일과 관련된 경우 compilation.getLogger를 사용하는 것이 좋으며 통계 안에 저장됩니다. 컴파일 주기 밖에서 발생하는 로깅의 경우에는 대신 compiler.getInfrastructureLogger를 사용하세요.

Logger methods

logger.error(...): 에러 메시지용입니다.
logger.warn(...): 경고용입니다.
logger.info(...): 중요 정보성 메시지용입니다. 이러한 메시지는 기본적으로 표시됩니다. 사용자가 실제로 봐야하는 메시지에만 사용합니다.
logger.log(...): 중요하지 않은 정보성 메시지용입니다. 이러한 메시지는 사용자가 볼 수 있도록 선택한 경우에만 표시됩니다.
logger.debug(...): 디버깅 정보용입니다. 이러한 메시지는 사용자가 특정 모듈에 대한 디버그 로깅을 보기로 선택한 경우에만 표시됩니다.
logger.trace(): 스택 추적을 표시하기 위해 사용합니다. logger.debug처럼 표시됩니다.
logger.group(...): 메시지를 그룹화하기 위해 사용합니다. logger.log처럼 접힌 채로 표시됩니다.
logger.groupEnd(): 로깅 그룹을 종료하기 위해 사용합니다.
logger.groupCollapsed(...): 메시지를 함께 그룹화하기 위해 사용합니다. logger.log처럼 접힌 채로 표시됩니다. 로깅 수준이 'verbose' 나 'debug'로 설정된 경우 확장되어 표시됩니다.
logger.status: 임시 메시지를 작성하고, 새 상태를 설정하고, 이전 메시지를 재정의합니다.
logger.clear(): 수평 라인을 출력합니다. logger.log처럼 표시됩니다.
logger.profile(...), logger.profileEnd(...): 프로파일을 캡처하기 위해 사용합니다. 지원되는 경우 console.profile에 위임됩니다.

Runtime Logger API

런타임 로거 API는 개발 도구로만 사용할 수 있고 프로덕션 모드에 포함할 수 없습니다.

const logging = require('webpack/lib/logging/runtime'): 런타임에서 로거를 사용하려면 webpack에서 직접 require 해야 합니다.
logging.getLogger('name'): 이름으로 개별 로거를 가져오기 위해 사용합니다.
logging.configureDefaultLogger(...): 기본 로거를 재정의합니다.

const logging = require('webpack/lib/logging/runtime');
logging.configureDefaultLogger({
  level: 'log',
  debug: /something/,
});

logging.hooks.log: 런타임 로거에 플러그인을 적용하기 위해 사용합니다.

Module Methods

이 섹션에서는 webpack으로 컴파일된 코드에서 사용할 수 있는 모든 메서드를 다룹니다. Webpack을 사용하여 애플리케이션을 번들할 때 ES6, CommonJS 및 AMD와 같은 여러 가지 구문 스타일 중 선택할 수 있습니다.

Webpack은 여러 모듈 구문을 지원하지만, 일관성을 유지하고 이상한 동작이나 버그를 피하려면 단일 구문을 따르는 것이 좋습니다. 실제로 webpack은 가장 가까운 상위 package.json 파일에 값이 "module" 이거나 commonjs인 "type" 필드가 포함된 경우, .mjs 파일, .cjs 파일 또는 .js 파일에 대한 권장 사항을 적용합니다. 계속해서 읽기 전에 다음 적용 사항을 알아보세요.

package.json에 "type": "module"이 있는 .mjs 또는 .js.
- CommonJS가 허용되지 않습니다. 예를 들면 require, module.exports 또는 exports를 사용할 수 없습니다.
- 가져올 때 파일 확장자가 필요합니다. 예를 들어 import './src/App' 대신에 import './src/App.mjs'를 사용해야 합니다. (Rule.resolve.fullySpecified를 사용하여 이 사항을 비활성화할 수 있습니다.)
package.json에 "type": "commonjs"가 있는 .cjs 또는 .js.
- import도 export도 사용할 수 없습니다.
package.json에 "type": "module"이 있는 .wasm.
- wasm 파일을 가져올 때 파일 확장자가 필요합니다.

ES6 (Recommended)

Webpack 버전 2는 기본적으로 ES6 모듈 구문을 지원합니다. 즉, babel과 같은 도구 없이 import 및 export를 사용하여 이를 처리할 수 있습니다. 다른 ES6+ 기능에는 여전히 babel이 필요할 수 있습니다. Webpack이 지원하는 메서드는 다음과 같습니다.

import

다른 모듈의 export를 정적으로 import 합니다.

import MyModule from './my-module.js';
import { NamedExport } from './other-module.js';

Data URI를 import 할 수도 있습니다.

import 'data:text/javascript;charset=utf-8;base64,Y29uc29sZS5sb2coJ2lubGluZSAxJyk7';
import {
  number,
  fn,
} from 'data:text/javascript;charset=utf-8;base64,ZXhwb3J0IGNvbnN0IG51bWJlciA9IDQyOwpleHBvcnQgY29uc3QgZm4gPSAoKSA9PiAiSGVsbG8gd29ybGQiOw==';

export

무엇이든 default 또는 이름이 지정된 내보내기로 내보냅니다.

// 이름이 지정된 내보내기
export var Count = 5;
export function Multiply(a, b) {
  return a * b;
}

// 기본 내보내기
export default {
  // 데이터...
};

import()

function(string path):Promise

모듈을 동적으로 로드합니다. import()에 대한 호출은 분할 지점으로 처리됩니다. 즉, 요청된 모듈과 그 자식은 별도의 청크로 분할됩니다.

if (module.hot) {
  import('lodash').then((_) => {
    // lodash(일명 '_')로 작업 수행...
  });
}

Dynamic expressions in import()

import(foo)와 같은 완전히 동적인 import 문을 사용하는 것은 불가능합니다. foo는 잠재적으로 시스템이나 프로젝트의 모든 파일에 대한 경로가 될 수 있기 때문입니다.

import()는 최소한 모듈 위치에 대한 정보를 포함해야 합니다. 번들링은 특정 디렉터리 또는 파일 집합으로 제한될 수 있습니다. 그러므로 동적 표현 식을 사용할 때 import() 호출 시 잠재적으로 요청 가능한 모든 모듈이 포함됩니다. 예를 들어 import(`./locale/${language}.json`)은 ./locale 디렉터리의 모든 .json 파일을 새로운 청크로 번들합니다. 런타임에 language 변수가 계산되면 english.json 또는 german.json과 같은 모든 파일이 사용 가능하게 됩니다.

// 쿠키나 다른 저장소에서 언어를 가져오는 방법이 있다고 상상해 보세요.
const language = detectVisitorLanguage();
import(`./locale/${language}.json`).then((module) => {
  // 번역과 관련된 작업을 수행합니다.
});

Magic Comments

기능을 작동시키기 위한 인라인 주석입니다. 가져오기에 주석을 추가하여 청크의 이름을 지정하거나 다른 모드를 선택하는 등의 여러 작업을 할 수 있습니다. 이 특별한 주석의 전체 목록과 주석이 수행하는 작업은 아래 코드와 설명을 참고하세요.

// 단일 대상
import(
  /* webpackChunkName: "my-chunk-name" */
  /* webpackMode: "lazy" */
  /* webpackExports: ["default", "named"] */
  /* webpackFetchPriority: "high" */
  'module'
);

// 여러 가능한 대상
import(
  /* webpackInclude: /\.json$/ */
  /* webpackExclude: /\.noimport\.json$/ */
  /* webpackChunkName: "my-chunk-name" */
  /* webpackMode: "lazy" */
  /* webpackPrefetch: true */
  /* webpackPreload: true */
  `./locale/${language}`
);

import(/* webpackIgnore: true */ 'ignored-module.js');

new URL(/* webpackIgnore: true */ 'file1.css', import.meta.url);

webpackIgnore

true로 설정하면 동적 import 구문 파싱을 비활성화합니다.

import.meta.url을 사용할 때, 그대로 유지되지 않고, 대신 baseURI에 따라 대체됩니다. 모듈의 경우 new URL("./", import.meta.url)로 대체되고, 다른 경우에는 document.baseURI로 기본 설정됩니다. 이렇게 하면 기본 URL 컨텍스트에 맞게 상대 URL이 올바르게 작동합니다.

webpackChunkName

새 청크의 이름입니다. Webpack 2.6.0부터 플레이스홀더 [index]와 [request]는 주어진 문자열 내에서 증가된 숫자 또는 실제 확인된 파일 이름으로 각각 지원합니다. 이 주석을 추가하면 개별 청크 이름이 [id].js 대신 [my-chunk-name].js로 지정됩니다.

webpackFetchPriority

5.87.0+

특정 동적 import에 대한 fetchPriority를 설정합니다. module.parser.javascript.dynamicImportFetchPriority 옵션을 사용하여 모든 동적 import에 전역 기본값을 설정할 수도 있습니다.

import(
  /* webpackFetchPriority: "high" */
  'path/to/module'
);

webpackMode

Webpack 2.6.0부터 동적 import를 해석하기 위한 다른 모드를 지정할 수 있습니다. 다음 옵션이 지원됩니다.

'lazy' (기본값): 각 import()된 모듈에 대해 지연 로드 가능한 청크를 생성합니다.
'lazy-once': import()에 대한 모든 호출을 만족시킬 수 있는 단일 지연 로드 가능 청크를 생성합니다. 청크는 import()에 대한 첫 번째 호출에서 가져오고, import()에 대한 후속 호출은 동일한 네트워크 응답을 사용합니다. 이것은 잠재적으로 요청 가능한 복수의 모듈 경로가 있는 import(`./locales/${language}.json`)와 같은 부분 동적 문일 경우에만 의미가 있습니다.
'eager': 추가 청크를 생성하지 않습니다. 모든 모듈은 현재 청크에 포함되며 추가 네트워크 요청은 발생하지 않습니다. 이미 해석된 Promise가 반환됩니다. 정적 가져오기와 달리 모듈은 import()가 호출될 때까지 실행되지 않습니다.
'weak': 모듈 함수가 이미 다른 방식으로 로드된 경우 모듈 로드를 시도합니다(예: 다른 청크가 이를 가져왔거나 모듈을 포함하는 스크립트가 로드된 경우). Promise가 여전히 반환되지만 청크가 이미 클라이언트에 있는 경우에만 성공적으로 해석됩니다. 모듈을 사용할 수 없으면 Promise가 거부됩니다. 네트워크 요청은 발생하지 않습니다. 이는 필요한 청크가 초기 요청에서 항상 수동으로 제공되는 (페이지에 내장된 경우) 범용 렌더링에 유용합니다. 하지만 앱 탐색이 초기에 제공되지 않은 가져오기를 트리거 하는 경우에는 유용하지 않습니다.

webpackPrefetch

향후 탐색에 리소스가 필요할 수 있음을 브라우저에 알립니다. webpackPrefetch 작동 방식에 대한 자세한 내용은 가이드를 확인하세요.

webpackPreload

현재 탐색 중에 리소스가 필요할 수 있음을 브라우저에 알립니다. webpackPreload 작동 방식에 대한 자세한 내용은 가이드를 확인하세요.

webpackInclude

가져오기 해석 중 일치하는지 확인할 정규식입니다. 일치하는 모듈만 번들로 제공됩니다.

webpackExclude

가져오기 해석 중 일치하는지 확인할 정규식입니다. 일치하는 모듈은 번들로 제공되지 않습니다.

webpackExports

webpackExports: 동적으로 import()된 모듈의 지정된 내보내기만 번들로 묶도록 webpack에 지시합니다. 청크의 출력 크기를 줄일 수 있습니다. webpack 5.0.0-beta.18부터 사용 가능합니다.

CommonJS

CommonJS의 목표는 브라우저 외부에서 JavaScript용 생태계를 지정하는 것입니다. Webpack에서 지원하는 CommonJS 메서드는 다음과 같습니다.

require

require(dependency: String);

다른 모듈의 내보내기를 동기적으로 검색합니다. 컴파일러는 출력 번들에서 의존성을 사용할 수 있는지 확인합니다.

var $ = require('jquery');
var myModule = require('my-module');

require에 대한 특별한 주석도 활성화할 수 있습니다. 자세한 내용은 module.parser.javascript.commonjsMagicComments를 참고하세요.

require.resolve

require.resolve(dependency: String);

모듈의 ID를 동기적으로 검색합니다. 컴파일러는 출력 번들에서 의존성을 사용할 수 있는지 확인합니다. require.cache[id] 또는 __webpack_require__(id)와 함께 사용할 수 있는 불투명 값으로 처리하는 것이 좋습니다 (이러한 사용을 피하는 것이 가장 좋습니다).

자세한 내용은 module.id를 참고하세요.

require.cache

동일한 모듈을 여러 번 require 하면 모듈이 한 번만 실행되고 하나의 내보내기만 발생합니다. 따라서 런타임에 캐시가 존재합니다. 이 캐시에서 값을 제거하면 새 모듈이 실행되고 새 내보내기가 발생합니다.

var d1 = require('dependency');
require('dependency') === d1;
delete require.cache[require.resolve('dependency')];
require('dependency') !== d1;

// file.js에서
require.cache[module.id] === module;
require('./file.js') === module.exports;
delete require.cache[module.id];
require.cache[module.id] === undefined;
require('./file.js') !== module.exports; // 이론상 실제로 이것은 스택 오버플로를 일으킵니다.
require.cache[module.id] !== module;

require.ensure

require.ensure(
  dependencies: String[],
  callback: function(require),
  errorCallback: function(error),
  chunkName: String
)

비동기식으로 로드될 지정된 dependencies를 별도의 번들로 분할합니다. CommonJS 모듈 구문을 사용할 때 이것은 의존성을 동적으로 로드하는 유일한 방법입니다. 즉, 이 코드는 작업 중에 실행될 수 있으며 특정 조건이 충족되는 경우에만 dependencies를 로드합니다.

var a = require('normal-dep');

if (module.hot) {
  require.ensure(['b'], function (require) {
    var c = require('c');

    // 특별한 작업을 수행...
  });
}

다음 파라미터는 위에서 지정한 순서대로 지원됩니다.

dependencies: callback의 코드 실행에 필요한 모든 모듈을 선언하는 문자열 배열입니다.
callback: 의존성이 로드되면 webpack이 실행할 함수입니다. require 함수 구현은 이 함수에 대한 파라미터로 전송됩니다. 함수 본문은 이것을 사용하여 실행에 필요한 추가 require() 모듈을 사용할 수 있습니다.
errorCallback: Webpack이 의존성을 불러오지 못했을 때 실행되는 함수입니다.
chunkName: 특별히 이 require.ensure()에 의해 생성된 청크에 부여된 이름입니다. 다양한 require.ensure() 호출에 동일한 chunkName을 전달하면 해당 코드를 단일 청크로 결합할 수 있으므로 브라우저에서 로드하는 번들이 하나만 생성됩니다.

AMD

AMD(Asynchronous Module Definition)는 모듈을 작성하고 로드하기 위한 인터페이스를 정의하는 JavaScript 사양입니다. Webpack에서 지원하는 AMD 방식은 다음과 같습니다.

define (with factory)

define([name: String], [dependencies: String[]], factoryMethod: function(...))

dependencies가 제공되면 factoryMethod가 각 의존성의 내보내기와 함께 같은 순서로 호출됩니다. dependencies가 제공되지 않으면 factoryMethod가 require, exports 및 module과 함께 호출됩니다(호환성을 위함입니다!). 이 함수가 값을 반환하면 모듈에서 이 값을 내보냅니다. 컴파일러는 각 의존성을 사용할 수 있는지 확인합니다.

define(['jquery', 'my-module'], function ($, myModule) {
  // $와 myModule로 작업을 수행하세요...

  // 함수 내보내기
  return function doSomething() {
    // ...
  };
});

define (with value)

define(value: !Function)

제공된 value를 내보냅니다. 여기서 value는 함수를 제외한 모든 것이 될 수 있습니다.

define({
  answer: 42,
});

require (amd-version)

require(dependencies: String[], [callback: function(...)])

require.ensure와 유사하게, 주어진 dependencies를 비동기식으로 로드되는 별도의 번들로 분할합니다. callback은 dependencies 배열의 각 종속성을 내보낼 때 호출됩니다.

require(['b'], function (b) {
  var c = require('c');
});

Labeled Modules

내부 LabeledModulesPlugin을 통해 모듈 내에서 다음과 같은 내보내기 및 요청을 위한 메서드 사용이 가능합니다.

export label

제공된 value를 내보냅니다. label은 함수 선언이나 변수 선언 앞에 올 수 있습니다. 함수 이름 또는 변수 이름은 값을 내보내는 데 사용되는 식별자입니다.

export: var answer = 42;
export: function method(value) {
  // 작업을 수행하세요...
};

require label

현재 범위에서 사용 가능한 의존성의 모든 내보내기를 만듭니다. require label은 문자열 앞에 올 수 있습니다. 의존성은 export label이 있는 값을 내보내야 합니다. CommonJS 또는 AMD 모듈은 사용할 수 없습니다.

some-dependency.js

export: var answer = 42;
export: function method(value) {
  // 작업을 수행하세요...
};

require: 'some-dependency';
console.log(answer);
method(...);

Webpack

위에서 설명한 모듈 구문 외에도 webpack에 한정된 몇가지 사용자 정의 메서드를 허용합니다.

require.context

require.context(
  (directory: String),
  (includeSubdirs: Boolean) /* 선택, 기본값 true */,
  (filter: RegExp) /* 선택, 기본값 /^\.\/.*$/, 모든 파일 */,
  (mode: String) /* 선택, 'sync' | 'eager' | 'weak' | 'lazy' | 'lazy-once', 기본값 'sync' */
);

directory에 대한 경로, includeSubdirs 옵션, 포함된 모듈을 좀 더 세밀하게 제어하기 위한 filter, 로드 작동 방식을 정의하는 mode를 사용하여 전체 의존성 그룹을 지정합니다. 그러면 기본 모듈은 나중에 해석할 수 있습니다.

var context = require.context('components', true, /\.html$/);
var componentA = context.resolve('componentA');

mode가 'lazy'로 설정되면 기본 모듈이 비동기식으로 로드됩니다.

var context = require.context('locales', true, /\.json$/, 'lazy');
context('localeA').then((locale) => {
  // locale로 작업을 수행
});

사용 가능한 모드의 전체 목록과 그 동작은 import() 문서에 설명되어 있습니다.

require.include

require.include((dependency: String));

실행하지 않고 dependency를 포함합니다. 출력 청크에서 모듈의 위치를 최적화하는 데 사용할 수 있습니다.

require.include('a');
require.ensure(['a', 'b'], function (require) {
  /* ... */
});
require.ensure(['a', 'c'], function (require) {
  /* ... */
});

결과는 다음과 같습니다.

엔트리 청크: file.js 와 a
익명 청크: b
익명 청크: c

require.include('a')가 없으면 두 익명 청크에 복제됩니다.

require.resolveWeak

require.resolve와 유사하지만, module을 번들로 가져오지 않습니다. 이것은 "약한" 의존성으로 간주합니다.

if (__webpack_modules__[require.resolveWeak('module')]) {
  // 모듈을 사용할 수 있을 때 수행...
}
if (require.cache[require.resolveWeak('module')]) {
  // 이전에 모듈이 로드된 경우 수행...
}

// 동적 해석("context")을 수행할 수 있습니다.
// 다른 require/import 메서드와 유사합니다.
const page = 'Foo';
__webpack_modules__[require.resolveWeak(`./page/${page}`)];

warning

모듈 소스에 정적으로 분석할 수 없는 요구 사항이 포함되어 있으면, 중요한 종속성 경고가 표시됩니다.

예제 코드:

someFn(require);
require.bind(null);
require(variable);

Module Variables

이 섹션에서는 webpack으로 컴파일된 코드에서 사용할 수 있는 모든 변수를 다룹니다. 모듈은 module 및 기타 변수를 통해 컴파일 프로세스의 특정 데이터에 접근할 수 있습니다.

module.loaded (NodeJS)

모듈이 현재 실행 중이면 false이고, 실행이 완료되면 true입니다.

module.hot (webpack-specific)

Hot Module Replacement가 활성화되었는지 여부를 나타내며 프로세스를 위한 인터페이스를 제공합니다. 자세한 내용은 HMR API 페이지를 참고하세요.

module.id (CommonJS)

현재 모듈의 ID입니다.

module.id === require.resolve('./file.js');

module.exports (CommonJS)

사용자가 모듈을 require 호출할 때 반환할 값을 정의합니다 (기본값은 새 객체).

module.exports = function doSomething() {
  // Do something...
};

exports (CommonJS)

이 변수는 module.exports(즉. 객체)의 기본값과 같습니다. module.exports를 덮어쓰면, exports를 더 내보내지 않습니다.

exports.someValue = 42;
exports.anObject = {
  x: 123,
};
exports.aFunction = function doSomething() {
  // Do something
};

global (NodeJS)

node.js global을 참고하세요.

호환성을 위해 webpack은 기본적으로 global 변수를 폴리필합니다.

__dirname (NodeJS)

node.__dirname의 설정 옵션은 다음과 같습니다.

false: 정의되지 않음
mock: '/'와 같음
true: node.js __dirname

파서에 의해 파싱되는 표현식 내부에서 사용되는 경우, 설정 옵션은 true로 처리됩니다.

import.meta

import.meta는 모듈의 URL과 같은 컨텍스트별 메타데이터를 JavaScript 모듈에 노출합니다. ESM에서만 사용할 수 있습니다.

Webpack은 import.meta에 대한 직접 액세스를 지원하지 않습니다. 대신 해당 속성에 액세스하거나 디스트럭처링 할당을 사용해야 합니다. 예를 들면,

// webpack은 이에 대해 경고할 것입니다.
Object.keys(import.meta);

// 사용해도 괜찮습니다.
console.log(import.meta.url);
const { url } = import.meta;

import.meta.url

모듈의 절대 file: URL을 반환합니다.

src/index.js

console.log(import.meta.url); // `file:///path/to/your/project/src/index.js`와 같은 출력

import.meta.webpack

webpack 버전을 반환합니다.

src/index.js

console.log(import.meta.webpack); // webpack 5의 경우 `5` 출력

import.meta.webpackHot

Webpack 특유의 속성입니다. module.hot의 별칭으로, import.meta.webpackHot은 strict ESM에서 사용할 수 있지만 module.hot은 할 수 없습니다.

import.meta.webpackContext

require.context와 동일한 값을 반환하지만 javascript/auto 및 javascript/esm에 대해서만 반환합니다.

Type:

(
  request: string,
  options?: {
    recursive?: boolean;
    regExp?: RegExp;
    include?: RegExp;
    exclude?: RegExp;
    preload?: boolean | number;
    prefetch?: boolean | number;
    chunkName?: string;
    exports?: string | string[][];
    mode?: 'sync' | 'eager' | 'weak' | 'lazy' | 'lazy-once';
  }
) => webpack.Context;

Available: 5.70.0+

Example:

const contextRequire = import.meta.webpackContext('.', {
  recursive: false,
  regExp: /two/,
  mode: 'weak',
  exclude: /three/,
});

__filename (NodeJS)

node.__filename의 설정 옵션은 다음과 같습니다.

false: 정의되지 않음
mock: '/index.js'와 같음
true: node.js __filename

파서에 의해 파싱되는 표현식 내부에서 사용되는 경우, 설정 옵션은 true로 처리됩니다.

__resourceQuery (webpack-specific)

현재 모듈의 리소스 쿼리입니다. 다음 require가 호출된 경우, 쿼리 문자열은 file.js에서 사용할 수 있습니다.

require('file.js?test');

file.js

__resourceQuery === '?test';

__webpack_public_path__ (webpack-specific)

설정 옵션의 output.publicPath와 동일합니다.

__webpack_require__ (webpack-specific)

원시 요청 함수입니다. 이 표현식은 파서에 의해 의존성이 파싱되지 않습니다.

__webpack_chunk_load__ (webpack-specific)

내부 청크 로딩 함수. 하나의 인수를 가집니다.

chunkId는 로드할 청크의 ID입니다.

하나가 실패했을 때 대체 퍼블릭 경로에서 청크를 로드하는 예제입니다.

const originalLoad = __webpack_chunk_load__;
const publicPaths = ['a', 'b', 'c'];
__webpack_chunk_load__ = async (id) => {
  let error;
  for (const path of publicPaths) {
    __webpack_public_path__ = path;
    try {
      return await originalLoad(id);
    } catch (e) {
      error = e;
    }
  }
  throw error;
};
import('./module-a').then((moduleA) => {
  // 이제 webpack은 사용자 정의 __webpack_chunk_load__ 를 사용하여 청크를 로드합니다.
});

__webpack_module__ (webpack-specific)

5.68.0+

현재의 모듈에 접근할 수 있습니다. 엄격한 ESM에서는 모듈을 사용할 수 없습니다.

__webpack_module__.id (webpack-specific)

5.68.0+

현재 모듈(module.id)의 ID에 접근할 수 있습니다. 엄격한 ESM에서는 모듈을 사용할 수 없습니다.

__webpack_modules__ (webpack-specific)

모든 모듈의 내부 객체에 대한 접근을 제공합니다.

__webpack_hash__ (webpack-specific)

컴파일의 해시에 대한 접근을 제공합니다.

__webpack_get_script_filename__ (webpack-specific)

function (chunkId)

id로 청크의 파일 이름을 제공합니다.

할당 가능하기 때문에 런타임에서 사용하는 파일 이름을 변경할 수 있습니다. 예를 들면 청크를 로드할 때 최종 경로를 결정하는 데 사용할 수 있습니다.

const oldFn = __webpack_get_script_filename__;

__webpack_get_script_filename__ = (chunkId) => {
  const filename = oldFn(chunkId);
  return filename + '.changed';
};

__non_webpack_require__ (webpack-specific)

webpack에 의해 파싱되지 않는 require 함수를 생성합니다. 가능한 경우 전역 요청 함수로 멋진 작업을 수행하는데 사용할 수 있습니다.

__webpack_exports_info__ (webpack-specific)

모듈에서, __webpack_exports_info__는 export 내부 검사를 허용하는데 사용할 수 있습니다.

__webpack_exports_info__는 항상 true입니다.
__webpack_exports_info__.<exportName>.used는 export가 사용되지 않는 경우 false이고, 그렇지 않으면 true입니다.
__webpack_exports_info__.<exportName>.useInfo는 다음과 같습니다.
- export가 사용되지 않는 경우 false
- export가 사용되는 경우 true
- export 사용이 런타임 조건에 따라 달라질 수 있는 경우 `null
  
  `
- 정보가 없을 경우 undefined
__webpack_exports_info__.<exportName>.provideInfo는 다음과 같습니다.
- export가 제공되지 않는 경우 false
- export가 제공되는 경우 true
- export 규정이 런타임 조건에 따라 달라질 수 있는 경우 `null
  
  `
- 정보가 없을 경우 undefined
nested export에서 정보에 접근할 수 있습니다. 예. __webpack_exports_info__.<exportName>.<exportName>.<exportName>.used
export가 __webpack_exports_info__.<name>.canMangle로 맹글링될 수 있는지 확인합니다.

__webpack_is_included__ (webpack-specific)

5.16.0+

주어진 모듈이 webpack에 의해 번들 되어 있는지 테스트합니다.

if (__webpack_is_included__('./module-a.js')) {
  // do something
}

__webpack_base_uri__ (webpack-specific)

런타임에 기본 URI를 변경합니다.

Type: string
Available: 5.21.0+

Example:

__webpack_base_uri__ = 'https://example.com';

__webpack_runtime_id__

현재 엔트리의 runtime id에 접근합니다.

이것은 webpack의 고유 기능이며 webpack 5.25.0부터 사용할 수 있습니다.

src/index.js

console.log(__webpack_runtime_id__ === 'main');

DEBUG (webpack-specific)

설정 옵션 debug와 동일합니다.

Compiler Hooks

Compiler 모듈은 CLI 또는 Node API를 통해 전달된 모든 옵션으로 컴파일 인스턴스를 생성하는 메인 엔진입니다. 플러그인 등록 및 호출을 위해 Tapable클래스를 확장합니다. 대부분의 사용자용 플러그인은 먼저 Compiler에 등록됩니다.

Webpack 플러그인을 개발할 때, 훅이 어디서 호출되는지 알고 싶을 수 있습니다. 이를 알아 보려면 webpack 소스코드에서 hooks.<hook name>.call을 검색해보세요.

Watching

Compiler는 파일 시스템을 모니터링하고 파일이 변경되면 다시 컴파일하는 watching을 지원합니다. watch 모드에서 컴파일러는 watchRun, watchClose 및 invalid와 같은 추가 이벤트를 내보냅니다. 이것은 일반적으로 development에서 사용되며 webpack-dev-server와 같은 도구의 내부에서 사용되어 개발자가 매번 수동으로 다시 컴파일할 필요 없게 도와줍니다. watch 모드는 CLI를 통해서도 시작 할 수 있습니다.

Hooks

아래에서 소개할 라이프 사이클 훅들은 compiler에 의해 노출됩니다. 아래와 같이 접근 할 수 있습니다.

compiler.hooks.someHook.tap('MyPlugin', (params) => {
  /* ... */
});

훅 타입에 따라서 tapAsync와 tapPromise를 사용할 수 있습니다.

훅 타입에 대한 설명은 Tapable 문서를 참고하세요.

environment

SyncHook

설정 파일에서 플러그인을 초기화한 직후, 컴파일러 환경을 준비하는 동안 호출됩니다.

afterEnvironment

SyncHook

컴파일러 환경 설정이 완료된 때인 environment 훅 바로 뒤에 호출됩니다.

entryOption

SyncBailHook

webpack 옵션의 entry 설정이 처리된 후 호출됩니다.

콜백 파라미터: context, entry

compiler.hooks.entryOption.tap('MyPlugin', (context, entry) => {
  /* ... */
});

afterPlugins

SyncHook

내부 플러그인의 초기 설정이 완료된 후 호출됩니다.

콜백 파라미터: compiler

afterResolvers

SyncHook

리졸버 설정이 완료된 후 트리거됩니다.

콜백 파라미터: compiler

initialize

SyncHook

컴파일러 객체가 초기화될 때 호출됩니다.

beforeRun

AsyncSeriesHook

컴파일러를 실행하기 직전에 훅을 추가합니다.

콜백 파라미터: compiler

run

AsyncSeriesHook

컴파일러가 records를 읽기 시작하기 전에 연결합니다.

콜백 파라미터: compiler

watchRun

AsyncSeriesHook

새 컴파일이 트리거된 후 컴파일이 실제로 시작되기 전에 watch 모드에서 플러그인을 실행합니다.

콜백 파라미터: compiler

normalModuleFactory

SyncHook

NormalModuleFactory가 생성된 후 호출됩니다.

콜백 파라미터: normalModuleFactory

contextModuleFactory

SyncHook

ContextModuleFactory가 생성된 후 플러그인을 실행합니다.

콜백 파라미터: contextModuleFactory

beforeCompile

AsyncSeriesHook

컴파일 파라미터가 생성된 후 플러그인을 실행합니다.

콜백 파라미터: compilationParams

compilationParams 변수는 다음과 같이 초기화됩니다.

compilationParams = {
  normalModuleFactory,
  contextModuleFactory,
};

이 훅은 컴파일 파라미터를 추가 또는 수정하는 데 사용할 수 있습니다.

compiler.hooks.beforeCompile.tapAsync('MyPlugin', (params, callback) => {
  params['MyPlugin - data'] = 'important stuff my plugin will use later';
  callback();
});

compile

SyncHook

새 컴파일이 생성되기 전인 beforeCompile 바로 뒤에 호출됩니다. 이 훅은 자식 컴파일러에 복사되지 않습니다.

콜백 파라미터: compilationParams

thisCompilation

SyncHook

컴파일을 초기화하는 동안 compilation 이벤트를 생성하기 직전에 실행됩니다. 이 훅은 자식 컴파일러에 복사되지 않습니다.

콜백 파라미터: compilation, compilationParams

compilation

SyncHook

컴파일이 생성된 후 플러그인을 실행합니다.

콜백 파라미터: compilation, compilationParams

make

AsyncParallelHook

컴파일을 완료하기 전에 실행됩니다. 이 훅은 자식 컴파일러에 복사되지 않습니다.

콜백 파라미터: compilation

afterCompile

AsyncSeriesHook

컴파일을 완료하고 봉인한 후 호출됩니다.

콜백 파라미터: compilation

shouldEmit

SyncBailHook

애셋을 방출하기 전에 호출됩니다. 방출 여부를 알려주는 boolean을 반환해야 합니다.

콜백 파라미터: compilation

compiler.hooks.shouldEmit.tap('MyPlugin', (compilation) => {
  // 출력을 내보내려면 true를 반환하고, 그렇지 않으면 false를 반환합니다.
  return true;
});

emit

AsyncSeriesHook

애셋을 출력 디렉터리로 방출하기 직전에 실행됩니다. 이 훅은 자식 컴파일러에 복사되지 않습니다.

콜백 파라미터: compilation

afterEmit

AsyncSeriesHook

출력 디렉터리에 애셋을 내보낸 후 호출됩니다. 이 훅은 자식 컴파일러에 복사되지 않습니다.

콜백 파라미터: compilation

assetEmitted

AsyncSeriesHook

애셋이 방출되었을 때 실행됩니다. 출력 경로 및 바이트 콘텐츠와 같은 내보낸 애셋의 정보에 대한 접근을 제공합니다.

콜백 파라미터: file, info

예를 들어 info.content를 통해 애셋의 콘텐츠 버퍼에 접근할 수 있습니다.

compiler.hooks.assetEmitted.tap(
  'MyPlugin',
  (file, { content, source, outputPath, compilation, targetPath }) => {
    console.log(content); // <Buffer 66 6f 6f 62 61 72>
  }
);

done

AsyncSeriesHook

컴파일이 완료되면 실행됩니다. 이 훅은 자식 컴파일러에 복사되지 않습니다.

콜백 파라미터: stats

additionalPass

AsyncSeriesHook

이 훅을 사용하면 빌드를 한 번 더 추가할 수 있습니다.

failed

SyncHook

컴파일이 실패하면 호출됩니다.

콜백 파라미터: error

invalid

SyncHook

감시중인 컴파일이 무효가 되었을 때 실행됩니다. 이 훅은 자식 컴파일러에 복사되지 않습니다.

콜백 파라미터: fileName, changeTime

watchClose

SyncHook

감시중인 컴파일이 중지되었을 때 호출됩니다.

shutdown

AsyncSeriesHook

컴파일러가 닫힐 때 호출됩니다.

infrastructureLog

SyncBailHook

infrastructureLogging 옵션을 통해 설정에서 활성화된 경우 인프라 로깅을 사용할 수 있습니다.

콜백 파라미터: name, type, args

log

SyncBailHook

활성화되면 stats에 로그를 작성할 수 있습니다. stats.logging, stats.loggingDebug 및 stats.loggingTrace 옵션을 참고하세요.

콜백 파라미터: origin, logEntry

Compilation Hooks

Compilation 모듈은 Compiler에서 새 컴파일 또는 빌드를 만드는 데 사용됩니다. compilation 객체는 모든 모듈과 해당 모듈의 디펜던시에 접근할 수 있습니다(대부분 순환 참조). 또한 애플리케이션의 디펜던시 그래프에 있는 모든 모듈의 리터럴 컴파일입니다. 컴파일 단계 동안 모듈은 로드, 봉인, 최적화, 청크, 해시 및 복원됩니다.

Compilation 클래스는 Tapable을 확장하고 다음과 같은 생명주기 훅을 제공합니다. 컴파일러 훅과 같은 방식으로 탭할 수 있습니다.

compilation.hooks.someHook.tap(/* ... */);

compiler와 마찬가지로 tapAsync 및 tapPromise도 훅 유형에 따라 사용할 수 있습니다.

buildModule

SyncHook

모듈 빌드가 시작되기 전에 트리거되며 모듈을 수정하는 데 사용할 수 있습니다.

콜백 파라미터: module

compilation.hooks.buildModule.tap(
  'SourceMapDevToolModuleOptionsPlugin',
  (module) => {
    module.useSourceMap = true;
  }
);

rebuildModule

SyncHook

모듈을 다시 빌드하기 전에 시작됩니다.

콜백 파라미터: module

failedModule

SyncHook

모듈 빌드가 실패하면 실행합니다.

콜백 파라미터: module error

succeedModule

SyncHook

모듈이 성공적으로 빌드되었을 때 실행됩니다.

콜백 파라미터: module

finishModules

AsyncSeriesHook

모든 모듈이 에러없이 빌드되었을 때 호출됩니다.

콜백 파라미터: modules

finishRebuildingModule

SyncHook

성공하거나 에러가 있는 경우 모듈이 다시 빌드 될 때 실행됩니다.

콜백 파라미터: module

seal

SyncHook

컴파일이 새로운 모듈을 받는 것이 중지되면 시작됩니다.

unseal

SyncHook

컴파일이 새로운 모듈을 받기 시작할 때 시작됩니다.

optimizeDependencies

SyncBailHook

디펜던시 최적화가 시작할 때 시작됩니다.

콜백 파라미터: modules

afterOptimizeDependencies

SyncHook

디펜던시 최적화 후 시작됩니다.

콜백 파라미터: modules

afterChunks

SyncHook

5.83.0+

'afterChunks' 훅은 청크 및 모듈 그래프 생성 후 최적화 전에 호출됩니다. 이 훅은 필요한 경우 청크 그래프를 검사, 분석 및 수정할 수 있는 기회를 제공합니다.

다음은 compilation.hooks.afterChunks 훅을 활용하는 방법에 대한 예시입니다.

콜백 파라미터: chunks

optimize

SyncHook

최적화 단계가 시작될 때 트리거됩니다.

optimizeModules

SyncBailHook

모듈 최적화 단계가 시작될 때 호출됩니다. 플러그인은 이 훅을 활용하여 모듈에 대한 최적화를 수행할 수 있습니다.

콜백 파라미터: modules

afterOptimizeModules

SyncHook

모듈 최적화가 완료된 후 호출됩니다.

콜백 파라미터: modules

optimizeChunks

SyncBailHook

청크 최적화 단계가 시작될 때 호출됩니다. 플러그인은 이 훅을 활용하여 청크에 대한 최적화를 수행할 수 있습니다.

콜백 파라미터: chunks

afterOptimizeChunks

SyncHook

청크 최적화가 완료된 후 시작됩니다.

콜백 파라미터: chunks

optimizeTree

AsyncSeriesHook

디펜던시 트리를 최적화하기 전에 호출됩니다. 플러그인은 이 훅을 활용하여 디펜던시 트리 최적화를 수행할 수 있습니다.

콜백 파라미터: chunks modules

afterOptimizeTree

SyncHook

디펜던시 트리 최적화가 성공적으로 완료된 후에 호출됩니다.

콜백 파라미터: chunks modules

optimizeChunkModules

SyncBailHook

청크 모듈 최적화 시작시 트리 최적화 후에 호출됩니다. 플러그인은 이 훅을 활용하여 청크 모듈의 최적화를 수행할 수 있습니다.

콜백 파라미터: chunks modules

afterOptimizeChunkModules

SyncHook

청크 모듈 최적화가 성공적으로 완료된 후에 호출됩니다.

콜백 파라미터: chunks modules

shouldRecord

SyncBailHook

레코드 저장 여부를 결정하기 위해 호출됩니다. !== false를 반환하면 다른 모든 "record" 훅이 실행되지 않습니다(record, recordModules, recordChunks 그리고 recordHash).

reviveModules

SyncHook

레코드에서 모듈 정보를 복원합니다.

콜백 파라미터: modules records

beforeModuleIds

SyncHook

각 모듈에 id를 할당하기 전에 실행됩니다.

콜백 파라미터: modules

moduleIds

SyncHook

각 모듈에 id를 할당하기 위해 호출됩니다.

콜백 파라미터: modules

optimizeModuleIds

SyncHook

모듈 id 최적화 시작시 호출됩니다.

콜백 파라미터: modules

afterOptimizeModuleIds

SyncHook

모듈 id 최적화 단계가 완료되면 호출됩니다.

콜백 파라미터: modules

reviveChunks

SyncHook

레코드에서 청크 정보를 복원합니다.

콜백 파라미터: chunks records

beforeChunkIds

SyncHook

각 청크에 id를 할당하기 전에 실행됩니다.

콜백 파라미터: chunks

chunkIds

SyncHook

각 청크에 id를 할당하기 위해 호출됩니다.

콜백 파라미터: chunks

optimizeChunkIds

SyncHook

청크 id 최적화 단계 시작시 호출됩니다.

콜백 파라미터: chunks

afterOptimizeChunkIds

SyncHook

청크 id 최적화가 완료된 후에 트리거됩니다.

콜백 파라미터: chunks

recordModules

SyncHook

레코드에 모듈 정보를 저장합니다. 이것은 shouldRecord가 참과 같은 값을 반환하는 경우 트리거됩니다.

콜백 파라미터: modules records

recordChunks

SyncHook

청크 정보를 레코드에 저장합니다. 이는 shouldRecord가 참과 같은 값을 반환하는 경우에만 트리거됩니다.

콜백 파라미터: chunks records

beforeModuleHash

SyncHook

모듈이 해시되기 전에 호출됩니다.

afterModuleHash

syncHook

모듈이 해시 된 후에 호출됩니다.

beforeHash

SyncHook

컴파일이 해시되기 전에 호출됩니다.

afterHash

SyncHook

컴파일이 해시되기 전에 호출됩니다.

recordHash

SyncHook

레코드 해시에 대한 정보를 records에 저장합니다. 이는 shouldRecord가 참과 같은 값을 반환하는 경우에만 트리거됩니다.

콜백 파라미터: records

record

SyncHook

compilation에 대한 정보를 records에 저장합니다. 이는 shouldRecord가 참과 같은 값을 반환하는 경우에만 트리거됩니다.

콜백 파라미터: compilation records

beforeModuleAssets

SyncHook

모듈 애셋이 생성되기 전에 실행됩니다.

additionalChunkAssets

SyncHook

청크에 대한 추가 애셋을 만듭니다.

콜백 파라미터: chunks

shouldGenerateChunkAssets

SyncBailHook

청크 애셋을 만들지 결정하기 위해 호출됩니다. !== false를 반환하면 청크 애셋을 생성합니다.

beforeChunkAssets

SyncHook

청크 애셋을 만들기 전에 실행됩니다.

additionalAssets

AsyncSeriesHook

컴파일을 위한 추가 애셋을 만듭니다. 이 훅은 이미지를 다운로드하는 데 사용할 수 있습니다. 예를 들면 다음과 같습니다.

compilation.hooks.additionalAssets.tapAsync('MyPlugin', (callback) => {
  download('https://img.shields.io/npm/v/webpack.svg', function (resp) {
    if (resp.status === 200) {
      compilation.assets['webpack-version.svg'] = toAsset(resp);
      callback();
    } else {
      callback(
        new Error('[webpack-example-plugin] Unable to download the image')
      );
    }
  });
});

optimizeChunkAssets

AsyncSeriesHook

청크 애셋을 최적화하세요. 애셋은 compilation.assets에 저장됩니다. Chunk에는 청크로 생성된 모든 파일을 가리키는 files 프로퍼티가 있습니다. 추가 청크 애셋은 compilation.additionalChunkAssets에 저장됩니다.

콜백 파라미터: chunks

다음은 단순히 각 청크에 배너를 추가하는 예시입니다.

compilation.hooks.optimizeChunkAssets.tapAsync(
  'MyPlugin',
  (chunks, callback) => {
    chunks.forEach((chunk) => {
      chunk.files.forEach((file) => {
        compilation.assets[file] = new ConcatSource(
          '/**Sweet Banner**/',
          '\n',
          compilation.assets[file]
        );
      });
    });

    callback();
  }
);

afterOptimizeChunkAssets

SyncHook

청크 애셋이 최적화된 후에 호출됩니다.

콜백 파라미터: chunks

다음은 각 청크에 들어간 내용을 정확히 출력하는 @boopathi의 플러그인 예시입니다.

compilation.hooks.afterOptimizeChunkAssets.tap('MyPlugin', (chunks) => {
  chunks.forEach((chunk) => {
    console.log({
      id: chunk.id,
      name: chunk.name,
      includes: chunk.getModules().map((module) => module.request),
    });
  });
});

optimizeAssets

AsyncSeriesHook

compilation.assets에 저장된 모든 애셋을 최적화합니다.

콜백 파라미터: assets

afterOptimizeAssets

SyncHook

애셋이 최적화된 후에 호출됩니다.

콜백 파라미터: assets

processAssets

AsyncSeriesHook

애셋을 처리합니다.

훅 파라미터:

name: string — 플러그인의 이름
stage: Stage — 활용되는 단계. 아래의 지원되는 단계 목록을 참고하세요.
additionalAssets?: true | (assets, [callback]) => (void | Promise<void>) — 추가 애셋을 위한 콜백. 아래를 참고하세요.

콜백 파라미터:

assets: { [pathname: string]: Source } — 키는 애셋의 경로 이름이고 값은 Source로 표시되는 애셋의 데이터인 순수 객체입니다.

예시

compilation.hooks.processAssets.tap(
  {
    name: 'MyPlugin',
    stage: Compilation.PROCESS_ASSETS_STAGE_ADDITIONS, // 더 많은 단계는 아래를 참고하세요.
  },
  (assets) => {
    console.log('List of assets and their sizes:');
    Object.entries(assets).forEach(([pathname, source]) => {
      console.log(`— ${pathname}: ${source.size()} bytes`);
    });
  }
);

Additional assets

name 및 stage 외에도 true 값을 허용하는 additionalAssets 5.8.0+ 옵션 또는 assets을 첫 번째 인수로 받는 콜백 함수를 전달할 수 있습니다.

true — 나중에 플러그인에 의해 추가된 애셋에 대해 제공된 콜백을 다시 실행하세요.

이 모드에서 콜백은 지정된 단계 이전에 추가된 애셋에 대해 한 번, 나중에 플러그인에 의해 추가된 애셋에 대해 이 단계 또는 다음 단계에 추가로 여러 번 호출됩니다.
```
compilation.hooks.processAssets.tap(
  {
    name: 'MyPlugin',
    stage: Compilation.PROCESS_ASSETS_STAGE_DEV_TOOLING,
    additionalAssets: true,
  },
  (assets) => {
    // 이 함수는 각각의 에셋에 대해 여러 번 호출됩니다.
  }
);
```

(assets, [callback]) => (void | Promise<void>) — 나중에 플러그인에서 추가한 애셋에 대해 이 단계 또는 다음 단계에서 지정된 콜백을 실행합니다. 콜백은 사용 된 탭 방법의 유형을 존중해야합니다. 예를 들면, tapPromise ()와 함께 사용하면 프로미스를 반환해야합니다.

compilation.hooks.processAssets.tap(
  {
    name: 'MyPlugin',
    stage: Compilation.PROCESS_ASSETS_STAGE_DEV_TOOLING,
    additionalAssets: (assets) => {
      // 이 함수는 이후 단계에서 추가된 애셋에 대해 여러번 호출될 가능성이 있습니다.
    },
  },
  (assets) => {
    // 이 함수는 이전 단계에서 플러그인에 의해 추가된 애셋에 대해 한 번 호출됩니다.
  }
);

List of asset processing stages

다음은 지원되는 단계를 처리 순서대로 나열한 목록입니다.

PROCESS_ASSETS_STAGE_ADDITIONAL — 컴파일에 추가 애셋을 추가합니다.
PROCESS_ASSETS_STAGE_PRE_PROCESS — 애셋의 기본 전처리.
PROCESS_ASSETS_STAGE_DERIVED — 기존 애셋에서 새 애셋을 가져옵니다.
PROCESS_ASSETS_STAGE_ADDITIONS — 기존 애셋에 배너 또는 초기화 코드 같은 추가 섹션을 추가합니다.
PROCESS_ASSETS_STAGE_OPTIMIZE — 일반적인 방식으로 기존 애셋을 최적화합니다.
PROCESS_ASSETS_STAGE_OPTIMIZE_COUNT — 기존 애셋의 수를 최적화합니다(예. 애셋 병합).
PROCESS_ASSETS_STAGE_OPTIMIZE_COMPATIBILITY — 기존 애셋의 호환성 최적화(예. 폴리필 또는 vendor 접두사 추가).
PROCESS_ASSETS_STAGE_OPTIMIZE_SIZE — 기존 애셋의 크기 최적화(예. 공백을 최소화하거나 생략).
PROCESS_ASSETS_STAGE_DEV_TOOLING — 애셋에 개발 도구 추가(예. 소스맵 추출)
PROCESS_ASSETS_STAGE_OPTIMIZE_INLINE 5.8.0+ — 기존 애셋 수 최적화(예. 애셋을 다른 애셋에 인라인으로 추가).
PROCESS_ASSETS_STAGE_SUMMARIZE — 기존 애셋 목록을 요약합니다.
PROCESS_ASSETS_STAGE_OPTIMIZE_HASH — 애셋의 해시를 최적화합니다(예. 애셋 콘텐츠의 실제 해시를 생성).
PROCESS_ASSETS_STAGE_OPTIMIZE_TRANSFER — 기존 애셋의 전송 최적화(예. 압축(gzip) 파일을 별도의 애셋으로 준비).
PROCESS_ASSETS_STAGE_ANALYSE — 기존 애셋을 분석합니다.
PROCESS_ASSETS_STAGE_REPORT — 리포팅 목적으로 애셋을 생성합니다.

Assets info

훅에 "asset info" 메타 데이터가 자동으로 제공되지 않습니다. 필요한 경우 컴파일 인스턴스와 제공된 애셋 경로 이름을 사용하여 이 메타 데이터를 수동으로 해결해야 합니다. 이것은 webpack의 차기 버전에서 개선될 것입니다.

Example:

compilation.hooks.processAssets.tap(
  {
    /** … */
  },
  (assets) => {
    Object.entries(assets).forEach(([pathname, source]) => {
      const assetInfo = compilation.assetsInfo.get(pathname);
      // @todo: "pathname", "source" 및 "assetInfo"를 사용하여 작업해줍니다.
    });
  }
);

afterProcessAssets

SyncHook

processAssets 훅이 에러없이 완료된 후에 호출됩니다.

needAdditionalSeal

SyncBailHook

다른 파일을 포함하기 위해 컴파일을 봉인 해제해야 하는지 확인하기 위해 호출됩니다.

afterSeal

AsyncSeriesHook

needAdditionalSeal 바로 뒤에 실행됩니다.

chunkHash

SyncHook

각 청크에 대한 해시를 방출하도록 트리거됩니다.

콜백 파라미터: chunk chunkHash

moduleAsset

SyncHook

모듈의 애셋이 컴파일에 추가될 때 호출됩니다.

콜백 파라미터: module filename

chunkAsset

SyncHook

청크의 애셋이 컴파일에 추가될 때 트리거됩니다.

콜백 파라미터: chunk filename

assetPath

SyncWaterfallHook

애셋의 경로를 결정하기 위해 호출됩니다.

콜백 파라미터: path options

needAdditionalPass

SyncBailHook

애셋이 방출된 후 추가로 처리되어야 하는지 여부를 판별하기 위해 호출됩니다.

childCompiler

SyncHook

자식 컴파일러를 설정한 후 실행됩니다.

콜백 파라미터: childCompiler compilerName compilerIndex

normalModuleLoader

webpack v5부터 normalModuleLoader 훅이 제거되었기 때문에, 이제 로더에 액세스하려면 NormalModule.getCompilationHooks(compilation).loader를 사용하세요.

statsPreset

HookMap

이 HookMap은 사전 설정이 사용될 때 트리거되는 작업 목록과 같습니다. 옵션 객체를 사용합니다. 플러그인이 사전 설정을 관리할 때에는 기존 설정을 바꾸지 않고 이 객체의 설정을 신중하게 변경해야 합니다.

콜백 파라미터: options context

플러그인 예시는 다음과 같습니다.

compilation.hooks.statsPreset.for('my-preset').tap('MyPlugin', (options) => {
  if (options.all === undefined) options.all = true;
});

이 플러그인은 사전 설정 'my-preset'에 대해 all 옵션이 정의되지 않은 경우 기본값이 true로 설정되도록 합니다.

statsNormalize

SyncHook

이 훅은 옵션 객체를 후속 흑에서 쉽게 사용할 수 있는 일관된 형식으로 변환하는 데 사용됩니다. 또한 누락된 옵션이 기본값으로 설정되도록 보장합니다.

콜백 파라미터: options context

플러그인 예시는 다음과 같습니다.

compilation.hooks.statsNormalize.tap('MyPlugin', (options) => {
  if (options.myOption === undefined) options.myOption = [];

  if (!Array.isArray(options.myOption)) options.myOptions = [options.myOptions];
});

이 플러그인에서는 myOption이 없으면 빈 배열로 설정합니다. 또한 myOption이 원래 단일 값으로 정의된 경우에도 항상 배열임을 보장합니다.

statsFactory

이 훅은 특정 옵션에서 StatsFactory 클래스에 대한 액세스를 제공합니다.

콜백 파라미터: statsFactory options

StatsFactory.hooks.extract

HookMap

콜백 파라미터: object data context

data에는 클래스가 포함되어 있습니다. object는 속성을 추가해야 하는 객체입니다. context는 경로의 클래스와 같은 상황별 정보를 제공합니다.

Example:

compilation.hooks.statsFactory.tap('MyPlugin', (statsFactory, options) => {
  statsFactory.hooks.extract
    .for('compilation')
    .tap('MyPlugin', (object, compilation) => {
      object.customProperty = MyPlugin.getCustomValue(compilation);
    });
});

StatsFactory.hooks.result

HookMap

각 레벨의 결과와 함께 호출됩니다.

콜백 파라미터: result context

statsPrinter

이 훅은 특정 옵션에서 StatsPrinter 클래스에 대한 액세스를 제공합니다.

콜백 파라미터: statsPrinter options

StatsPrinter.hooks.print

HookMap

이 훅은 파트를 출력해야 할 때 호출됩니다.

콜백 파라미터: object context

StatsPrinter.hooks.result

HookMap

이 훅은 파트의 결과 문자열에 대해 호출됩니다.

콜백 파라미터: result context

ContextModuleFactory Hooks

ContextModuleFactory 모듈은 webpack의 require.context API에서 디펜던시를 생성하기 위해 컴파일러에서 사용됩니다. 요청된 디렉터리를 확인하고, 각 파일에 대한 요청을 생성하며 전달된 정규 표현식으로 필터링합니다. 이 과정을 거쳐 일치하는 디펜던시만 NormalModuleFactory를 통과합니다.

ContextModuleFactory 클래스는 Tapable을 확장하고 다음과 같은 수명 주기 훅을 제공합니다. 아래와 같이 컴파일러 훅과 같은 방식으로 탭할 수 있습니다.

ContextModuleFactory.hooks.someHook.tap(/* ... */);

compiler와 마찬가지로 tapAsync와 tapPromise도 훅 유형에 따라 사용할 수 있습니다.

beforeResolve

AsyncSeriesWaterfallHook

요청된 디렉터리를 확인하기 전에 호출됩니다. false를 반환하여 요청을 무시할 수 있습니다.

콜백 파라미터: data

afterResolve

AsyncSeriesWaterfallHook

요청된 디렉터리가 확인된 후 호출됩니다.

콜백 파라미터: data

contextModuleFiles

SyncWaterfallHook

디렉터리 내용을 읽은 후 호출됩니다. 재귀 모드에서는 각 하위 디렉터리도 호출합니다. 콜백 파라미터는 각 디렉터리에 있는 모든 파일 및 폴더 이름의 배열입니다.

콜백 파라미터: fileNames

alternativeRequests

AsyncSeriesWaterfallHook

요청이 생성된 후 정규 표현식으로 필터링하기 전에 각 파일에 대해 호출됩니다.

콜백 파라미터: request options

JavascriptParser Hooks

compiler에 있는, parser 인스턴스는, webpack에서 처리 중인 각 모듈을 파싱하는 데 사용합니다. parser는 tapable을 확장하고 플러그인 작성자가 파싱 프로세스를 커스터마이징 하는데 사용할 수 있는 다양한 tapable 훅을 제공하는 또 다른 webpack 클래스입니다.

parser는 NormalModuleFactory에서 볼 수 있습니다.

compiler.hooks.normalModuleFactory.tap('MyPlugin', (factory) => {
  factory.hooks.parser
    .for('javascript/auto')
    .tap('MyPlugin', (parser, options) => {
      parser.hooks.someHook.tap(/* ... */);
    });
});

compiler와 마찬가지로, tapAsync 그리고 tapPromise도 훅 타입에 따라 사용할 수 있습니다.

Hooks

다음 라이프사이클 훅은 parser에 의해 노출되며 접근할 수 있습니다.

evaluateTypeof

SyncBailHook

자유 변수의 typeof로 구성된 표현식을 평가할 때 트리거 됩니다.

훅 파라미터: identifier
콜백 파라미터: expression

parser.hooks.evaluateTypeof
  .for('myIdentifier')
  .tap('MyPlugin', (expression) => {
    /* ... */
    return expressionResult;
  });

이것은 evaluateTypeof 훅을 트리거 합니다.

const a = typeof myIdentifier;

다음은 트리거 되지 않습니다.

const myIdentifier = 0;
const b = typeof myIdentifier;

evaluate

SyncBailHook

표현식을 평가할 때 호출됩니다.

훅 파라미터: expressionType
콜백 파라미터: expression

예제입니다.

index.js

const a = new String();

MyPlugin.js

parser.hooks.evaluate.for('NewExpression').tap('MyPlugin', (expression) => {
  /* ... */
  return expressionResult;
});

표현식 타입은 다음과 같습니다.

'ArrowFunctionExpression'
'AssignmentExpression'
'AwaitExpression'
'BinaryExpression'
'CallExpression'
'ClassExpression'
'ConditionalExpression'
'FunctionExpression'
'Identifier'
'LogicalExpression'
'MemberExpression'
'NewExpression'
'ObjectExpression'
'SequenceExpression'
'SpreadElement'
'TaggedTemplateExpression'
'TemplateLiteral'
'ThisExpression'
'UnaryExpression'
'UpdateExpression'

evaluateIdentifier

SyncBailHook

자유 변수인 식별자를 평가할 때 호출됩니다.

훅 파라미터: identifier
콜백 파라미터: expression

evaluateDefinedIdentifier

SyncBailHook

정의된 변수 식별자를 평가할 때 호출됩니다.

훅 파라미터: identifier
콜백 파라미터: expression

evaluateCallExpressionMember

SyncBailHook

성공적으로 평가된 표현식의 멤버 함수에 대한 호출을 평가할 때 호출됩니다.

훅 파라미터: identifier
콜백 파라미터: expression param

이 표현식은 다음의 훅을 트리거 합니다.

index.js

const a = expression.myFunc();

MyPlugin.js

parser.hooks.evaluateCallExpressionMember
  .for('myFunc')
  .tap('MyPlugin', (expression, param) => {
    /* ... */
    return expressionResult;
  });

statement

SyncBailHook

코드 조각에서 파싱된 모든 구문에 대해 호출되는 범용적 훅입니다.

콜백 파라미터: statement

parser.hooks.statement.tap('MyPlugin', (statement) => {
  /* ... */
});

statement.type은 다음과 같을 수 있습니다.

'BlockStatement'
'VariableDeclaration'
'FunctionDeclaration'
'ReturnStatement'
'ClassDeclaration'
'ExpressionStatement'
'ImportDeclaration'
'ExportAllDeclaration'
'ExportDefaultDeclaration'
'ExportNamedDeclaration'
'IfStatement'
'SwitchStatement'
'ForInStatement'
'ForOfStatement'
'ForStatement'
'WhileStatement'
'DoWhileStatement'
'ThrowStatement'
'TryStatement'
'LabeledStatement'
'WithStatement'

statementIf

SyncBailHook

if 구문을 파싱할 때 호출됩니다. statement 훅과 동일하지만, statement.type == 'IfStatement'인 경우에만 트리거 됩니다.

콜백 파라미터: statement

label

SyncBailHook

label이 있는 구문을 파싱할 때 호출됩니다. 이러한 구문에는 statement.type === 'LabeledStatement'가 있습니다.

훅 파라미터: labelName
콜백 파라미터: statement

import

SyncBailHook

코드 조각의 모든 import 구문에 대해 호출됩니다. source 파라미터에는 가져온 파일의 이름이 포함됩니다.

콜백 파라미터: statement source

다음의 import 구문은 훅을 한 번 트리거 합니다.

index.js

import _ from 'lodash';

MyPlugin.js

parser.hooks.import.tap('MyPlugin', (statement, source) => {
  // source == 'lodash'
});

importSpecifier

SyncBailHook

모든 import 구문의 모든 지정자에 대해 호출됩니다.

콜백 파라미터: statement source exportName identifierName

다음의 import 구문은 훅을 두 번 트리거 합니다.

index.js

import _, { has } from 'lodash';

MyPlugin.js

parser.hooks.importSpecifier.tap(
  'MyPlugin',
  (statement, source, exportName, identifierName) => {
    /* First call
    source == 'lodash'
    exportName == 'default'
    identifierName == '_'
  */
    /* Second call
    source == 'lodash'
    exportName == 'has'
    identifierName == 'has'
  */
  }
);

export

SyncBailHook

코드 조각의 모든 export 구문에 대해 호출됩니다.

콜백 파라미터: statement

exportImport

SyncBailHook

모든 export-import 구문에 대해 호출됩니다. 예. export * from 'otherModule';.

콜백 파라미터: statement source

exportDeclaration

SyncBailHook

선언을 내보내는 모든 export 구문에 대해 호출됩니다.

콜백 파라미터: statement declaration

이러한 내보내기는 다음의 훅을 트리거 합니다.

export const myVar = 'hello'; // 또한 var, let
export function FunctionName() {}
export class ClassName {}

exportExpression

SyncBailHook

표현식을 내보내는 모든 export 구문에 대해 호출됩니다. 예. export default expression;.

콜백 파라미터: statement declaration

exportSpecifier

SyncBailHook

모든 export 구문의 모든 지정자에 대해 호출됩니다.

콜백 파라미터: statement identifierName exportName index

exportImportSpecifier

SyncBailHook

모든 export-import 구문의 모든 지정자에 대해 호출됩니다.

콜백 파라미터: statement source identifierName exportName index

varDeclaration

SyncBailHook

변수 선언문을 파싱할 때 호출됩니다.

콜백 파라미터: declaration

varDeclarationLet

SyncBailHook

let을 사용해 정의된 변수 선언문을 파싱할 때 호출됩니다.

콜백 파라미터: declaration

varDeclarationConst

SyncBailHook

const를 사용해 정의된 변수 선언문을 파싱할 때 호출됩니다.

콜백 파라미터: declaration

varDeclarationVar

SyncBailHook

var를 사용해 정의된 변수 선언문을 파싱할 때 호출됩니다.

콜백 파라미터: declaration

canRename

SyncBailHook

이름 변경이 허용되는지 확인하기 위해 식별자의 이름을 변경하기 전에 트리거 됩니다. 일반적으로 rename 훅과 함께 사용됩니다.

훅 파라미터: identifier
콜백 파라미터: expression

var a = b;

parser.hooks.canRename.for('b').tap('MyPlugin', (expression) => {
  // true를 반환하면 이름을 변경할 수 있습니다.
  return true;
});

rename

SyncBailHook

새 식별자를 가져오기 위해 이름을 바꿀 때 트리거 됩니다. 이 훅은 canRename이 true를 반환하는 경우에 호출됩니다.

훅 파라미터: identifier
콜백 파라미터: expression

var a = b;

parser.hooks.rename.for('b').tap('MyPlugin', (expression) => {});

assigned

SyncBailHook

할당된 표현식을 파싱하기 전에 AssignmentExpression을 파싱할 경우에 호출됩니다.

훅 파라미터: identifier
콜백 파라미터: expression

a += b;

parser.hooks.assigned.for('a').tap('MyPlugin', (expression) => {
  // 이것은 b를 파싱하기 전에 호출됩니다.
});

assign

SyncBailHook

할당 표현식을 파싱하기 전에 AssignmentExpression을 파싱할 경우에 호출됩니다.

훅 파라미터: identifier
콜백 파라미터: expression

a += b;

parser.hooks.assigned.for('a').tap('MyPlugin', (expression) => {
  // 이것은 a를 파싱하기 전에 호출됩니다.
});

typeof

SyncBailHook

식별자의 typeof를 파싱할 때 트리거 됩니다.

훅 파라미터: identifier
콜백 파라미터: expression

call

SyncBailHook

함수 호출을 파싱할 때 호출됩니다.

훅 파라미터: identifier
콜백 파라미터: expression

eval(/* something */);

parser.hooks.call.for('eval').tap('MyPlugin', (expression) => {});

callMemberChain

SyncBailHook

객체의 멤버 함수에 대한 호출을 파싱할 경우 트리거 됩니다.

훅 파라미터: objectIdentifier
콜백 파라미터: expression, properties

myObj.anyFunc();

parser.hooks.callMemberChain
  .for('myObj')
  .tap('MyPlugin', (expression, properties) => {});

new

SyncBailHook

new 표현식을 파싱할 때 호출됩니다.

훅 파라미터: identifier
콜백 파라미터: expression

new MyClass();

parser.hooks.new.for('MyClass').tap('MyPlugin', (expression) => {});

expression

SyncBailHook

표현식을 파싱할 때 호출됩니다.

훅 파라미터: identifier
콜백 파라미터: expression

const a = this;

parser.hooks.expression.for('this').tap('MyPlugin', (expression) => {});

expressionConditionalOperator

SyncBailHook

ConditionalExpression을 파싱할 때 호출됩니다. 예. condition ? a : b

콜백 파라미터: expression

program

SyncBailHook

코드 조각의 추상 구문 트리(AST)에 접근합니다.

파라미터: ast comments

NormalModuleFactory Hooks

NormalModuleFactory 모듈은 컴파일러에서 모듈을 생성하는데 사용됩니다. 엔트리 포인트에서 시작하여 각 요청을 해결하고, 내용을 파싱하여 추가 요청을 찾고, 모든 파일을 해결함으로써 크롤링하고 새 파일을 파싱합니다. 마지막 단계에서는 각 의존성이 모듈 인스턴스가 됩니다.

NormalModuleFactory 클래스는 Tapable을 확장하고 다음과 같은 라이프사이클 훅을 제공합니다. 컴파일러 훅도 같은 방식으로 탭 할 수 있습니다.

NormalModuleFactory.hooks.someHook.tap(/* ... */);

NormaleModuleFactory는 HooksMaps에서 액세스 할 수 있는 파서와 제너레이터 인스턴스를 연결합니다.

NormalModuleFactory.hooks.someHook.for('identifier').tap(/* ... */);

컴파일러와 마찬가지로 tapAsync 및 tapPromise도 훅의 유형에 따라 사용할 수 있습니다.

beforeResolve

AsyncSeriesBailHook

새 의존성 요청이 발견되면 호출됩니다. 의존성은 false를 반환하여 무시할 수 있습니다. 그렇지 않으면 계속 진행하기 위해서는 undefined 상태로 반환되어야 합니다.

콜백 파라미터: resolveData

factorize

AsyncSeriesBailHook

해결을 시작하기 전에 호출됩니다. 계속 진행하기 위해서는 undefined 상태로 반환되어야 합니다.

콜백 파라미터: resolveData

resolve

AsyncSeriesBailHook

요청이 해결되기 전에 호출됩니다. false를 반환하여 의존성을 무시할 수 있습니다. 모듈 인스턴스를 반환하면 프로세스가 완료됩니다. 그렇지 않으면 계속 진행하기 위해서는 undefined 상태로 반환되어야 합니다.

콜백 파라미터: resolveData

resolveForScheme

AsyncSeriesBailHook

스킴(URI)과 요청이 해결되기 전에 .

콜백 파라미터: resolveData

afterResolve

AsyncSeriesBailHook

요청이 해결되면 호출됩니다.

콜백 파라미터: resolveData

createModule

AsyncSeriesBailHook

NormalModule 인스턴스를 만들기 전에 호출됩니다.

콜백 파라미터: createData resolveData

createModuleClass

HookMap<SyncBailHook>

5.81.0+

모듈을 생성할 때 NormalModule 클래스를 재정의할 수 있는 훅입니다. 이 훅은 createModule 훅 이후와 module 훅 이전에 호출됩니다.

훅 파라미터: identifier
콜백 파라미터: createData resolveData

module

SyncWaterfallHook

NormalModule 인스턴스를 만들기 전에 호출됩니다.

콜백 파라미터: module createData resolveData

createParser

HookMap<SyncBailHook>

파서 인스턴스를 만들기 전에 호출됩니다. parserOptions는 해당 식별자 또는 빈 개체에 대한 module.parser의 옵션입니다.

훅 파라미터: identifier
콜백 파라미터: parserOptions

parser

HookMap<SyncHook>

파서 인스턴스를 만든 후 발생합니다.

훅 파라미터: identifier
콜백 파라미터: parser parserOptions

가능한 기본 식별자:

javascript/auto
javascript/dynamic
javascript/esm
json
webassembly/sync
webassembly/async
asset

createGenerator

HookMap<SyncBailHook>

제너레이터 인스턴스를 만들기 전에 호출됩니다. generatorOptions는 해당 식별자 또는 빈 개체에 대한 module.parser의 옵션입니다.

훅 파라미터: identifier
콜백 파라미터: generatorOptions

generator

HookMap<SyncHook>

제너레이터 인스턴스를 만든 후 호출됩니다.

훅 파라미터: identifier
콜백 파라미터: generator generatorOptions

가능한 기본 식별자:

json
webassembly/sync
webassembly/async
asset
asset/source
asset/resource
asset/inline

Compilation Object

Compilation 객체에는 사용 가능한 많은 메소드와 훅이 있습니다. 이 페이지에서는, 사용 가능한 메소드와 프로퍼티를 나열합니다.

compilation object methods

getStats

function

현재 컴파일에 대한 State 객체를 반환합니다.

addModule

function (module, callback)

현재 컴파일에 모듈을 추가합니다.

파라미터:

module - 추가할 모듈.
callback - 모듈이 추가된 뒤의 콜백.

getModule

function (module)

식별자를 통해 컴파일에서 모듈을 가져옵니다.

파라미터:

module - 가져올 모듈. 식별자는 module.identifier() 메소드를 사용한 컴파일을 통해 모듈에서 추출됩니다.

findModule

function (module)

식별자로 모듈 검색을 시도합니다.

파라미터:

module - 검색할 모듈. 식별자는 module.identifier() 메소드를 사용한 컴파일을 통해 모듈에서 추출됩니다.

buildModule

function (module, optional, origin, dependencies)

주어진 모듈을 빌드합니다.

파라미터:

module - 빌드할 모듈.
optional - 선택적 플래그.
origin - 모듈 빌드가 요청된 원본 모듈.
dependencies - 빌드할 모듈의 선택적 의존성.

processModuleDependencies

function (module, callback)

주어진 모듈 의존성을 처리합니다.

파라미터:

module - 의존성에 대해 처리할 모듈.
callback - 모듈의 의존성이 처리되었을 때 호출되는 함수.

addEntry

function (context, entry, name, callback)

컴파일에 엔트리를 추가합니다.

파라미터:

context - 엔트리의 컨텍스트 경로.
entry - 엔트리 의존성.
name - 엔트리 이름.
callback - addEntry가 완료될 때 호출되는 함수.

rebuildModule

function (module, thisCallback)

모듈 재빌드를 트리거 합니다.

파라미터:

module - 재빌드 할 모듈.
thisCallback - 모듈이 재빌드를 마쳤을 때 호출되는 함수.

finish

function (callback)

컴파일을 완료하고 주어진 콜백을 호출합니다.

파라미터:

callback - 컴파일이 완료되면 호출되는 함수.

seal

function (callback)

컴파일을 봉인합니다.

파라미터:

callback - 컴파일이 봉인되었을 때 호출되는 함수.

unseal

function

컴파일 봉인을 해제합니다.

파라미터:

callback - 컴파일 봉인이 해제될 때 호출되는 함수.

reportDependencyErrorsAndWarnings

function (module, blocks)

컴파일 오류 및 경고에 주어진 모듈의 오류 및 경고를 추가합니다.

파라미터:

module - 오류 및 경고를 보고할 모듈.
blocks - 보고할 의존성 블록 집합.

addChunkInGroup

function (groupOptions, module, loc, request)

기존 청크 그룹에 모듈을 추가하거나 새 그룹을 만듭니다. chunkGroup을 반환합니다.

파라미터:

groupOptions - 청크 그룹에 대한 옵션.
module - 청크 그룹을 참조하는 모듈.
loc - 청크 그룹이 참조되는 위치(모듈 내부).
request - 청크 그룹이 참조되는 요청.

addChunk

function (name)

compilation.chunks에 새 청크를 만들고 추가합니다. 해당 chunk를 반환합니다.

파라미터:

name - 청크 이름.

assignDepth

function (module)

주어진 모듈과 그 의존성 블록에 재귀적으로 depth를 할당합니다.

파라미터:

module - depth를 할당할 모듈.

getDependencyReference

function (module, dependency)

주어진 모듈에서 의존성에 대한 참조를 반환합니다.

파라미터:

module - 주어진 모듈.
dependency - 참조할 의존성.

processDependenciesBlocksForChunkGroups

function (inputChunkGroups)

Module 그래프에서 Chunk 그래프를 생성합니다. 이 과정은 두 단계로 이루어집니다. 1단계: 모듈 그래프를 탐색하고 chunkDependencies에서 기본 청크 그래프를 빌드합니다. 2단계: 기본 청크 그래프를 통해 가능한 모든 방법을 탐색하고 사용 가능한 모듈을 추적합니다. 탐색하는 동안, processDependenciesBlocksForChunkGroups는 청크를 서로 연결하고 Blocks는 Chunks와 연결합니다. 청크에 대한 모든 모듈이 이미 사용 가능하고 불필요한 청크를 연결하지 않으면 탐색을 중지합니다.

파라미터:

inputChunkGroups - 처리되는 청크 그룹.

removeReasonsOfDependencyBlock

function (module, block)

모듈과 의존성 블록의 관계를 제거합니다.

파라미터:

module - 제거할 모듈 관계.
block - 의존성 블록.

patchChunksAfterReasonRemoval

function (module, chunk)

의존성 이유를 제거한 후 모듈 및 청크의 연결을 패치합니다. removeReasonsOfDependencyBlock에 의해 자동으로 호출됩니다.

파라미터:

module - 패치 할 모듈.
chunk - 패치 할 청크.

removeChunkFromDependencies

function (block, chunk)

의존성 이유를 제거한 후 의존성 블록 모듈 및 청크에서 주어진 청크를 제거합니다. removeReasonsOfDependencyBlock에 의해 자동으로 호출됩니다.

파라미터:

block - Chunk의 블록.
chunk - 의존성에서 제거할 청크.

sortItemsWithChunkIds

function

summarizeDependencies

function

createHash

function

createModuleAssets

function

createChunkAssets

function

getPath

function (filename, data)

삽입된 경로를 반환합니다.

파라미터:

filename - 해시로 애셋 경로를 얻는 데 사용.
data - data 객체.

getPathWithInfo

function (filename, data)

삽입된 경로 및 애셋 정보를 반환합니다.

파라미터:

filename - 해시로 애셋 경로를 얻는 데 사용.
data - data 객체.

createChildCompiler

function (name, outputOptions, plugins)

webpack 내에서 webpack의 다른 인스턴스를 실행할 수 있습니다. 그러나, 다른 설정과 구성이 적용된 하위 컴파일러로서 상위(또는 최상위 컴파일러)에서 모든 훅과 플러그인을 복사하고 하위 Compiler 인스턴스를 만듭니다. 생성된 Compiler를 반환합니다.

파라미터:

name - 하위 Compiler의 이름.
outputOptions - 출력 옵션 객체.
plugins - 적용될 webpack 플러그인.

checkConstraints

function

emitAsset

function (file, source, assetInfo = {})

파라미터:

file - 애셋의 파일 이름
source - 애셋의 소스
assetInfo - 추가 애셋 정보

updateAsset

function (file, newSourceOrFunction, assetInfoUpdateOrFunction)

파라미터:

file - 애셋의 파일 이름
newSourceOrFunction - 새 애셋 소스 또는 이전의 것을 새것으로 변환하는 함수
assetInfoUpdateOrFunction - 새 애셋 정보 또는 이전의 것을 새것으로 변환하는 함수

deleteAsset

function (file)

파라미터:

file - 애셋의 파일 이름

getAssets

function

현재 컴파일에서 모든 애셋의 배열을 반환합니다.

getAsset

function (name)

파라미터:

name - 반환할 애셋의 이름

Plugin API

플러그인은 webpack 생태계의 핵심 요소이며 커뮤니티에 webpack의 컴파일 프로세스를 활용할 수 있는 강력한 방법을 제공합니다. 플러그인은 각 컴파일 과정에서 발생하는 주요 이벤트에 후킹 할 수 있습니다. 모든 단계에서 플러그인은 컴파일러, 경우에 따라서는 현재 진행 중인 컴파일에 완전한 접근 권한을 가집니다.

먼저 webpack 플러그인 인터페이스의 근간을 제공하는 tapable 유틸리티에 대해 살펴보겠습니다.

Tapable

이 작은 라이브러리는 webpack의 핵심 유틸리티이지만 유사한 플러그인 인터페이스를 제공하기 위해 다른 곳에서도 사용할 수 있습니다. webpack의 많은 객체가 Tapable 클래스를 확장합니다. Tapable 클래스가 제공하는 tap, tapAsnyc, tapPromise 메소드를 플러그인에서 사용하여 컴파일 과정에서 실행될 커스텀 빌드 단계를 삽입할 수 있습니다.

자세한 내용은 문서를 참고하세요. 세 가지 tap 메소드와 이를 제공하는 훅을 이해하는 것은 중요합니다. Tapable을 확장한 객체(예: 컴파일러), 훅, 각 훅의 타입(예: SyncHook)에 대해 알게 될 것입니다.

Plugin Types

사용된 훅과 적용된 tap 메소드에 따라 플러그인은 다양한 방식으로 작동할 수 있습니다. 작동 방식은 Tapable이 제공하는 훅과 밀접한 관련이 있습니다. 컴파일러 훅은 상황에 따라 Tapable 훅을 통해 어떤 tap 메소드가 사용 가능한지 알 수 있습니다.

따라서 어떤 이벤트에 tap 하느냐에 따라 플러그인은 다르게 동작할 수 있습니다. 예를 들어, 컴파일 단계에 후킹 하는 경우 동기식 tap 메소드만 사용할 수 있습니다.

compiler.hooks.compile.tap('MyPlugin', (params) => {
  console.log('Synchronously tapping the compile hook.');
});

그러나 AsyncHook을 활용하는 run의 경우 tap뿐만 아니라 tapAsync 또는 tapPromise도 사용할 수 있습니다.

compiler.hooks.run.tapAsync(
  'MyPlugin',
  (source, target, routesList, callback) => {
    console.log('Asynchronously tapping the run hook.');
    callback();
  }
);

compiler.hooks.run.tapPromise('MyPlugin', (source, target, routesList) => {
  return new Promise((resolve) => setTimeout(resolve, 1000)).then(() => {
    console.log('Asynchronously tapping the run hook with a delay.');
  });
});

compiler.hooks.run.tapPromise(
  'MyPlugin',
  async (source, target, routesList) => {
    await new Promise((resolve) => setTimeout(resolve, 1000));
    console.log('Asynchronously tapping the run hook with a delay.');
  }
);

즉, 컴파일러에 후킹 하는 다양한 방법이 있으며, 각 방법은 플러그인에 적합하다면 실행될 수 있습니다.

Custom Hooks

다른 플러그인이 tap 할 수 있도록 컴파일에 사용자 정의 훅을 제공하려면, 다음을 수행해야 합니다.

컴파일 훅을 위한 모듈 범위 WeakMap을 만듭니다.

const compilationHooks = new WeakMap<Compilation, MyHooks>();

interface MyHooks {
  custom: SyncHook<[number, string]>;
}

플러그인에 정적 메서드를 만듭니다.

static getCompilationHooks(compilation: Compilation) : MyHooks {
  let hooks = compilationHooks.get(compilation);
  if(hooks === undefined) {
    compilationHooks.set(compilation, hooks = {
      custom: new SyncHook()
    });
  }
  return hooks;
}

플러그인에서 아래와 같이 훅을 호출합니다.

const hooks = MyPlugin.getCompilationHooks(compilation);

hooks.custom.call(1, 'hello');

다른 플러그인도 사용자 정의 훅에 접근할 수 있습니다.

import MyPlugin from 'my-plugin';

const hooks = MyPlugin.getCompilationHooks(compilation);

hooks.custom.tap('OtherPlugin', (n, s) => {
  // magic
});

다양한 훅 클래스와 동작 방식에 대해 자세히 알고 싶다면 tapable 문서를 참고하세요.

Reporting Progress

플러그인은 기본적으로 진행 상황을 stderr에 출력하는 ProgressPlugin을 통해 진행 상황을 확인할 수 있습니다. 진행률을 확인하려면 webpack CLI를 실행할 때 --progress 인수를 전달하세요.

ProgressPlugin의 reportProgress 함수에 다른 인수를 전달하여 메시지 출력을 커스텀 할 수 있습니다.

진행 상황을 확인하기 위해서는 context: true 옵션을 사용하여 훅에 tap 해야 합니다.

compiler.hooks.emit.tapAsync(
  {
    name: 'MyPlugin',
    context: true,
  },
  (context, compiler, callback) => {
    const reportProgress = context && context.reportProgress;
    if (reportProgress) reportProgress(0.95, 'Starting work');
    setTimeout(() => {
      if (reportProgress) reportProgress(0.95, 'Done work');
      callback();
    }, 1000);
  }
);

reportProgress 함수는 다음과 같은 인수를 사용하여 호출할 수 있습니다.

reportProgress(percentage, ...args);

percentage: 이 인수는 사용되지 않습니다. 대신 ProgressPlugin이 현재 훅을 기반으로 백분율을 계산합니다.
...args: ProgressPlugin 핸들러로 전달되는 임의의 수의 문자열입니다.

컴파일러 및 컴파일 훅의 하위 집합만이 reportProgress를 지원합니다. 전체 목록은 ProgressPlugin를 참고하세요.

Logging

로깅 API는 webpack 4.37 릴리스부터 사용할 수 있습니다. stats 설정에서 logging이 활성화된 경우 또는 infrastructure logging이 활성화된 경우 플러그인은 각 로거 형식(stats, infrastructure)으로 메시지를 로깅 할 수 있습니다.

플러그인은 로깅을 위해 compilation.getLogger('PluginName')를 사용하는 것이 좋습니다. 로그는 형식에 따라 포매팅 되어 Stats에 저장됩니다. 로그는 사용자가 필터링하고 내보낼 수 있습니다.
플러그인은 로깅을 위해 compiler.getInfrastructureLogger('PluginName')를 사용할 수 있습니다. infrastructure 로깅은 Stats에 저장되지 않기 때문에 형식이 지정되지 않습니다. 일반적으로 콘솔 / 대시보드 / GUI에 직접 기록됩니다. 사용자가 필터링 할 수 있습니다.
플러그인은 로깅 지원 여부를 확인하기 위해 특정한 폴백 로직 compilation.getLogger ? compilation.getLogger('PluginName') : console을 사용하여 컴파일 객체에서 getLogger 메소드를 지원하지 않는 이전 webpack 버전이 사용되는 경우에 대한 폴백을 제공 할 수 있습니다.

Next Steps

사용 가능한 모든 컴파일러 훅 및 파라미터에 대한 자세한 목록은 컴파일러 훅 섹션을 참고하세요.

Resolvers

리졸버는 enhanced-resolve 패키지를 사용하여 생성됩니다. Resolver 클래스는 tapable 클래스를 확장하고 tapable을 사용하여 몇 가지 hook을 제공합니다. enhanced-resolve 패키지를 사용하여 새 리졸버를 직접 만들 수 있습니다. 하지만 모든 컴파일러 인스턴스에는 탭 할 수 있는 몇 가지 리졸버 인스턴스가 있습니다.

계속 읽기 전에 enhanced-resolve 및 tapable 문서를 확인하세요.

Types

compiler 클래스에서 사용할 수 있는 내장 리졸버에는 세 가지 유형이 있습니다.

normal: 절대 또는 상대 경로를 통해 모듈을 해석합니다.
context: 주어진 컨텍스트 내에서 모듈을 해석합니다.
loader: webpack 로더를 해석합니다.

필요에 따라 컴파일러에서 사용하는 내장 리졸버 중 하나를, 플러그인을 통해 사용자 지정할 수 있습니다.

compiler.resolverFactory.hooks.resolver
  .for('[type]')
  .tap('name', (resolver) => {
    // 이제 resolver.hooks를 활용할 수 있습니다.
    resolver.hooks.result.tap('MyPlugin', (result) => {
      return result;
    });
  });

여기에서 [type]은 위에서 언급한 세 가지 리졸버 중 하나입니다.

hook의 전체 목록과 설명은 enhanced-resolve 문서를 참고하세요.

Configuration Options

위에서 언급한 리졸버는 resolve 또는 resolveLoader 옵션이 있는 설정 파일을 통해 사용자 지정할 수도 있습니다. 이러한 옵션을 통해 사용자는 resolve 플러그인을 비롯한 다양한 옵션을 통해 해석 동작을 변경할 수 있습니다.

예를 들면 DirectoryNamedPlugin과 같은 리졸버 플러그인은 플러그인 설정 옵션에서 사용하는 대신 resolve.plugins에 직접 포함될 수 있습니다.

Edit this page·Print this page

Printable

Introduction

CLI

Module

Node

Loaders

Plugins

Command Line Interface

Commands

Build

Init

Generation Path

Options

Loader

Output Path

Options

Plugin

Output Path

Options

Info

Options for info

Configtest

Config Path

Serve

Watch

Flags

Negated Flags

Core Flags

Usage

With configuration file

Without configuration file

entry

output-path

Default Configurations

Common Options

help

version

config

config-name

merge

extends

json

Environment Options

env

node-env

define-process-env-node-env

Configuration Options

Analyzing Bundle

Progress

Pass CLI arguments to Node.js

Exit codes and their meanings

CLI Environment Variables

WEBPACK_PACKAGE

Troubleshooting

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for ./webpack.config.ts

Node Interface

Installation

webpack()

Compiler Instance

Run

Watching

Close Watching

Invalidate Watching

Stats Object

stats.hasErrors()

stats.hasWarnings()

stats.toJson(options)

stats.toString(options)

MultiCompiler

Error Handling

Custom File Systems

Stats Data

Structure

Asset Objects

Chunk Objects

Module Objects

Entry Objects

Errors and Warnings

webpack-dev-server API

Installation

Close `Watching`

Invalidate `Watching`