Загрузчики веб-пакетов и плагины; какая разница?

104

В чем разница между загрузчиками и плагинами в webpack?

В документации для плагинов просто сказано:

Используйте плагины для добавления функций, обычно связанных с пакетами в webpack.

Я знаю, что babel использует загрузчик для преобразований jsx / es2015, но похоже, что другие общие задачи (например, copy-webpack-plugin) вместо этого используют плагины.

Тим Перкинс
источник
2
Загрузчик преобразует файлы в распознаваемые js (и что-то делает во время преобразования), плагины могут делать все, что им нужно, на выходе загрузчика.
Дэвид Гуан

Ответы:

62

Загрузчики выполняют преобразование предварительной обработки практически любого формата файла, когда вы используете sth like require("my-loader!./my-awesome-module")в своем коде. По сравнению с плагинами они довольно просты, поскольку (а) предоставляют только одну единственную функцию для webpack и (б) не могут влиять на фактический процесс сборки.

Плагины, с другой стороны, могут глубоко интегрироваться в веб-пакет, поскольку они могут регистрировать перехватчики в системе сборки веб-пакетов и получать доступ (и изменять) компилятор и то, как он работает, а также компиляцию. Следовательно, они более мощные, но их сложнее обслуживать.

привет
источник
почему загрузчик не может глубоко интегрироваться с webpack?
Нитин.
@NitinTyagi Потому что это работа плагинов. Цель загрузчиков - быть простой.
helt
157

Добавляем дополнительный и более простой ответ.

Погрузчики:

Загрузчики работают на уровне отдельных файлов во время или до создания пакета .

Плагины:

Плагины работают на уровне пакета или фрагмента и обычно работают в конце процесса создания пакета. Плагины также могут изменять способ создания самих пакетов. Плагины имеют более мощный контроль, чем загрузчики.

Просто для примера вы можете ясно увидеть на изображении ниже, где работают загрузчики и где работают плагины -

введите описание изображения здесь Ссылки: статья и изображение

WitVault
источник
36
Отлично сработано! Два простых предложения, и теперь я понимаю разницу. Теперь, пожалуйста, приступайте к переписыванию ВСЕЙ библиотеки документации веб-пакета, потому что это совершенно непонятная чушь.
rism 04
18

По своей сути webpack - это просто сборщик файлов. Учитывая очень простой сценарий (без разделения кода), это может означать только следующие действия (на высоком уровне):

  1. найти входной файл и загрузить его содержимое в память
  2. сопоставить определенный текст в контенте и оценить его (например, @import)
  3. найдите зависимости на основе предыдущей оценки и сделайте то же самое с ними
  4. сшить их все в связку в памяти
  5. записать результаты в файловую систему

Если вы внимательно изучите вышеуказанные шаги, это перекликается с тем, что делает компилятор Java (или любой другой компилятор). Конечно, есть различия, но они не имеют значения для понимания загрузчиков и плагинов.


Погрузчики:

здесь, потому что webpack обещает объединить файлы любого типа.

Поскольку webpack в своей основе способен только связывать файлы js, это обещание означало, что основная команда webpack должна была включить потоки сборки, которые позволили внешнему коду преобразовывать определенный тип файла таким образом, чтобы его мог использовать webpack.

Этот внешний код называется загрузчиками и обычно запускается на шагах 1 и 3 выше. Таким образом, поскольку этап, на котором эти загрузчики должны запускаться, очевиден, им не требуются перехватчики и они не влияют на процесс сборки (поскольку сборка или сборка происходит только на шаге 4).

Таким образом, загрузчики готовят почву для компиляции и как бы расширяют гибкость компилятора webpack.


Плагины:

здесь, потому что, хотя webpack напрямую не обещает переменный вывод, мир этого хочет, и webpack позволяет это.

Поскольку webpack по своей сути является просто сборщиком пакетов и при этом проходит несколько этапов и подэтапов, эти шаги можно использовать для создания дополнительных функций.

Процесс производственной сборки (минимизация и запись в файловую систему), который является встроенной возможностью компилятора webpack, например, может рассматриваться как расширение его основных возможностей (которое просто объединяется) и может рассматриваться как собственный плагин. Если бы они этого не сделали, это сделал бы кто-то другой.

Глядя на нативный плагин выше, кажется, что объединение или компиляция веб-пакетов можно разбить на основной процесс связывания плюс множество собственных процессов плагинов, которые мы можем отключить, настроить или расширить. Это означало, что внешнему коду разрешалось подключаться к процессу связывания в определенных точках, из которых они могли выбирать (так называемые перехватчики).

Таким образом, плагины влияют на вывод и как бы расширяют возможности компилятора webpack.

супи
источник
1
Отличный ответ, действительно рисует яркую картину
Robotron
Мне очень нравится этот ответ. Это дает вам некоторое объяснение, чтобы уметь рассуждать. Не только определение, но и понимание, стоящее за ним.
Дазаг
1

Загрузчики работают на файловом уровне . Они могут написать шаблон, обработать некоторый код для его преобразования в зависимости от вашего удобства и т. Д.

Плагины работают на системном уровне . Они могут работать с шаблоном, обработкой файловой системы (имя, путь) и т. Д.

Webwoman
источник