Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translate contribute/plugin-patterns.md #179

Merged
merged 14 commits into from
Sep 8, 2021
42 changes: 22 additions & 20 deletions src/content/contribute/plugin-patterns.mdx
Original file line number Diff line number Diff line change
@@ -5,33 +5,35 @@ contributors:
- nveenjain
- EugeneHlushko
- benglynn
translators:
- yoonminsohappy
---

Plugins grant unlimited opportunity to perform customizations within the webpack build system. This allows you to create custom asset types, perform unique build modifications, or even enhance the webpack runtime while using middleware. The following are some features of webpack that become useful while writing plugins.
플러그인은 webpack 빌드 시스템 내에서 커스터마이징을 수행할 수 있는 무한한 기회를 제공합니다. 이를 통해 커스텀 애셋 유형을 생성하고, 고유한 빌드 수정을 수행할 수 있게 하며, 심지어 미들웨어를 사용하는 동안 webpack 런타임을 향상시킬 수 있습니다. 다음은 플러그인을 작성할 때 유용하게 쓰이는 webpack의 몇 가지 기능입니다.

## Exploring assets, chunks, modules, and dependencies

After a compilation is sealed, all structures within the compilation may be traversed.
컴파일이 완료된 후에는, 컴파일 내의 모든 구조를 확인할 수 있습니다.

```javascript
class MyPlugin {
apply(compiler) {
compiler.hooks.emit.tapAsync('MyPlugin', (compilation, callback) => {
// Explore each chunk (build output):
// 각 청크(빌드 출력)를 탐색합니다.
compilation.chunks.forEach((chunk) => {
// Explore each module within the chunk (built inputs):
// 청크(빌드된 입력) 내의 각 모듈을 탐색합니다.
chunk.getModules().forEach((module) => {
// Explore each source file path that was included into the module:
// 모듈에 포함된 각 소스 파일 경로를 탐색합니다.
module.buildInfo &&
module.buildInfo.fileDependencies &&
module.buildInfo.fileDependencies.forEach((filepath) => {
// we've learned a lot about the source structure now...
// 이제 소스 구조에 대해 많은 것을 배웠습니다...
});
});

// Explore each asset filename generated by the chunk:
// 청크에 의해 생성된 각 애셋 파일 이름을 탐색합니다.
chunk.files.forEach((filename) => {
// Get the asset source for each file generated by the chunk:
// 청크에 의해 생성된 각 파일의 애셋 소스를 가져옵니다.
var source = compilation.assets[filename].source();
});
});
@@ -43,21 +45,21 @@ class MyPlugin {
module.exports = MyPlugin;
```

- `compilation.modules`: A set of modules (built inputs) in the compilation. Each module manages the build of a raw file from your source library.
- `compilation.modules`: 컴파일 결과물의 모듈(빌드된 입력) 집합입니다. 각 모듈은 소스 라이브러리의 원시 파일의 빌드를 관리합니다.

W> **Deprecation warning**: Array functions will still work.
W> **Deprecation warning**: 배열 함수는 계속 작동합니다.

- `module.fileDependencies`: An array of source file paths included into a module. This includes the source JavaScript file itself (ex: `index.js`), and all dependency asset files (stylesheets, images, etc) that it has required. Reviewing dependencies is useful for seeing what source files belong to a module.
- `compilation.chunks`: A set of chunks (build outputs) in the compilation. Each chunk manages the composition of a final rendered assets.
- `module.fileDependencies`: 모듈에 포함된 소스 파일 경로의 배열입니다. 이것은 자바스크립트 파일 자체(예: index.js)와 필요한 모든 의존성 애셋 파일들(스타일 시트, 이미지 등)을 포함합니다. 의존성을 검토하는 것은 어떤 소스 파일이 모듈에 속하는지 파악하는데 유용합니다.
- `compilation.chunks`: 컴파일의 청크 세트(빌드 출력)입니다. 각 청크는 최종 렌더링된 애셋의 구성을 관리합니다.

W> **Deprecation warning**: Array functions will still work.
W> **Deprecation warning**: 배열 함수는 계속 작동합니다.

- `chunk.getModules()`: An array of modules that are included into a chunk. By extension, you may look through each module's dependencies to see what raw source files fed into a chunk.
- `chunk.files`: A Set of output filenames generated by the chunk. You may access these asset sources from the `compilation.assets` table.
- `chunk.getModules()`: 청크에 포함된 모듈의 배열입니다. 각 모듈의 의존성을 통해 어떤 원시 소스 파일이 청크에 공급되는지 확인할 수 있습니다.
- `chunk.files`: 청크에 의해 생성된 출력 파일 이름의 집합입니다. `compilation.assets` 테이블에서 이러한 애셋 소스를 액세스할 수 있습니다.

### Monitoring the watch graph

While running webpack middleware, each compilation includes a `fileDependencies` `Set` (what files are being watched) and a `fileTimestamps` `Map` that maps watched file paths to a timestamp. These are extremely useful for detecting what files have changed within the compilation:
webpack 미들웨어를 실행하는 동안, 각 컴파일 결과물은 `fileDependencies` `Set` (감시되고 있는 파일) 그리고 된 파일 경로를 타임스탬프에 매핑하는 `fileTimestamps` `Map` 을 포함합니다. 다음은 컴파일 결과물 내에서 변경된 파일을 감지하는데 매우 유용합니다.

```javascript
class MyPlugin {
@@ -85,15 +87,15 @@ class MyPlugin {
module.exports = MyPlugin;
```

You may also feed new file paths into the watch graph to receive compilation triggers when those files change. Add valid file paths into the `compilation.fileDependencies` `Set` to add them to the watched files.
파일이 변경될 때 컴파일 트리거를 수신하도록 감시 그래프에 새로운 파일 경로를 제공할 수도 있습니다. 유효한 파일 경로를 `compilation.fileDependencies` `Set` 에 더하여 감시된 파일에 추가합니다.

T> The `fileDependencies` `Set` is rebuilt in each compilation, so your plugin must add its own watched dependencies into each compilation to keep them under watch.
T> `fileDependencies` `Set` 은 각 컴파일 결과물 내에서 다시 빌드되므로, 플러그인은 감시를 유지하기 위해 각 컴파일 결과물 자체에 감시된 의존성을 추가해야 합니다.

W> Since webpack 5, `compilation.fileDependencies`, `compilation.contextDependencies` and `compilation.missingDependencies` are now a `Set` instead of a `Sortable Set` and thus no longer sorted.
W> wepback 5부터, `compilation.fileDependencies` , `compilation.contextDependencies` 그리고 `compilation.missingDependencies` 는 이제 더 이상 `Sortable Set` 이 아니라 `Set` 이므로 정렬되지 않습니다.

## Changed chunks

Similar to the watch graph, you can monitor changed chunks (or modules, for that matter) within a compilation by tracking their hashes.
감시 그래프와 유사하게, 해시를 추적하여 컴파일 결과물 내에서 변경된 청크(또는 모듈)를 모니터링할 수 있습니다.

```javascript
class MyPlugin {