Webpack의 로더와 플러그인의 차이점은 무엇입니까?
플러그인을 사용하여 일반적으로 웹팩의 번들과 관련된 기능을 추가합니다.
babel이 jsx / es2015 변환에 로더를 사용한다는 것을 알고 있지만 다른 일반적인 작업 (예 : copy-webpack-plugin) 대신 플러그인을 사용하는 것처럼 보입니다.
답변:
로더는 require("my-loader!./my-awesome-module")코드에서 sth를 사용할 때 거의 모든 파일 형식의 전처리 변환을 수행합니다 . 플러그인에 비해 (a) 웹팩에 하나의 단일 기능 만 노출하고 (b) 실제 빌드 프로세스에 영향을 줄 수 없기 때문에 매우 간단합니다.
반면 플러그인은 웹팩 빌드 시스템 내에서 후크를 등록하고 컴파일러에 액세스 (및 수정) 할 수 있기 때문에 웹팩에 깊이 통합 될 수 있으며 컴파일뿐만 아니라 작동 방식도 가능합니다. 따라서 그들은 더 강력하지만 유지하기가 더 어렵습니다.
보완적이고 간단한 답변 추가.
로더 :
로더 는 번들 이 생성 되는 동안 또는 생성 되기 전에 개별 파일 수준에서 작동합니다 .
플러그인 :
플러그인은 번들 또는 청크 수준에서 작동하며 일반적으로 번들 생성 프로세스 가 끝날 때 작동 합니다. 플러그인은 번들 자체가 생성되는 방식을 수정할 수도 있습니다. 플러그인은 로더보다 더 강력한 제어 기능을 가지고 있습니다.
예를 들어 아래 이미지에서 로더가 작동하는 위치와 플러그인이 작동하는 위치를 명확하게 볼 수 있습니다.
핵심에서 webpack은 파일 번 들러입니다. 매우 간단한 시나리오 (코드 분할 없음)를 고려할 때 이는 다음 작업 (높은 수준에서)만을 의미 할 수 있습니다.
위의 단계를 자세히 살펴보면 Java 컴파일러 (또는 모든 컴파일러)가 수행하는 작업과 공감합니다. 물론 차이점이 있지만 로더와 플러그인을 이해하는 데는 중요하지 않습니다.
로더 :
webpack은 모든 파일 유형을 함께 묶을 것을 약속하기 때문에 여기에 있습니다.
핵심에있는 webpack은 js 파일을 번들링 할 수있을만큼만 가능하기 때문에이 약속은 webpack 핵심 팀이 외부 코드가 웹팩이 소비 할 수있는 방식으로 특정 파일 유형을 변환 할 수 있도록하는 빌드 흐름을 통합해야 함을 의미합니다.
이러한 외부 코드를 로더라고하며 일반적으로 위의 1 단계와 3 단계에서 실행됩니다. 따라서 이러한 로더를 실행해야하는 단계가 분명하기 때문에 후크가 필요하지 않으며 빌드 프로세스에도 영향을주지 않습니다 (빌드 또는 번들은 4 단계에서만 발생하기 때문에).
따라서 로더는 컴파일 단계를 준비하고 웹팩 컴파일러의 유연성을 확장합니다.
플러그인 :
웹팩이 변수 출력을 직접 약속하지는 않지만 세상이 원하고 웹팩이 허용하기 때문입니다.
핵심에있는 웹팩은 번들 러일 뿐이지 만 여러 단계와 하위 단계를 거치기 때문에 이러한 단계를 활용하여 추가 기능을 구축 할 수 있습니다.
예를 들어 웹팩 컴파일러의 기본 기능인 프로덕션 빌드 프로세스 (축소 및 파일 시스템에 쓰기)는 핵심 기능 (단지 번들링)의 확장으로 취급 될 수 있으며 기본 플러그인처럼 취급 될 수 있습니다. 그들이 그것을 제공하지 않았다면 다른 누군가가 그것을했을 것입니다.
위의 기본 플러그인을 보면 웹팩 번들링 또는 컴파일이 핵심 번들링 프로세스와 함께 끄거나 사용자 정의하거나 확장 할 수있는 많은 기본 플러그인 프로세스로 나눌 수있는 것처럼 보입니다. 이는 외부 코드가 선택할 수있는 특정 지점 (후크라고 함)에서 번들링 프로세스에 참여할 수 있음을 의미했습니다.
따라서 플러그인은 출력에 영향을 미치고 웹팩 컴파일러의 기능을 확장합니다.
