В чем разница между загрузчиками и плагинами в webpack?
В документации для плагинов просто сказано:
Используйте плагины для добавления функций, обычно связанных с пакетами в webpack.
Я знаю, что babel использует загрузчик для преобразований jsx / es2015, но похоже, что другие общие задачи (например, copy-webpack-plugin) вместо этого используют плагины.
Ответы:
Загрузчики выполняют преобразование предварительной обработки практически любого формата файла, когда вы используете sth like require("my-loader!./my-awesome-module")в своем коде. По сравнению с плагинами они довольно просты, поскольку (а) предоставляют только одну единственную функцию для webpack и (б) не могут влиять на фактический процесс сборки.
Плагины, с другой стороны, могут глубоко интегрироваться в веб-пакет, поскольку они могут регистрировать перехватчики в системе сборки веб-пакетов и получать доступ (и изменять) компилятор и то, как он работает, а также компиляцию. Следовательно, они более мощные, но их сложнее обслуживать.
Добавляем дополнительный и более простой ответ.
Погрузчики:
Загрузчики работают на уровне отдельных файлов во время или до создания пакета .
Плагины:
Плагины работают на уровне пакета или фрагмента и обычно работают в конце процесса создания пакета. Плагины также могут изменять способ создания самих пакетов. Плагины имеют более мощный контроль, чем загрузчики.
Просто для примера вы можете ясно увидеть на изображении ниже, где работают загрузчики и где работают плагины -
Ссылки:
статья и
изображение
По своей сути webpack - это просто сборщик файлов. Учитывая очень простой сценарий (без разделения кода), это может означать только следующие действия (на высоком уровне):
Если вы внимательно изучите вышеуказанные шаги, это перекликается с тем, что делает компилятор Java (или любой другой компилятор). Конечно, есть различия, но они не имеют значения для понимания загрузчиков и плагинов.
Погрузчики:
здесь, потому что webpack обещает объединить файлы любого типа.
Поскольку webpack в своей основе способен только связывать файлы js, это обещание означало, что основная команда webpack должна была включить потоки сборки, которые позволили внешнему коду преобразовывать определенный тип файла таким образом, чтобы его мог использовать webpack.
Этот внешний код называется загрузчиками и обычно запускается на шагах 1 и 3 выше. Таким образом, поскольку этап, на котором эти загрузчики должны запускаться, очевиден, им не требуются перехватчики и они не влияют на процесс сборки (поскольку сборка или сборка происходит только на шаге 4).
Таким образом, загрузчики готовят почву для компиляции и как бы расширяют гибкость компилятора webpack.
Плагины:
здесь, потому что, хотя webpack напрямую не обещает переменный вывод, мир этого хочет, и webpack позволяет это.
Поскольку webpack по своей сути является просто сборщиком пакетов и при этом проходит несколько этапов и подэтапов, эти шаги можно использовать для создания дополнительных функций.
Процесс производственной сборки (минимизация и запись в файловую систему), который является встроенной возможностью компилятора webpack, например, может рассматриваться как расширение его основных возможностей (которое просто объединяется) и может рассматриваться как собственный плагин. Если бы они этого не сделали, это сделал бы кто-то другой.
Глядя на нативный плагин выше, кажется, что объединение или компиляция веб-пакетов можно разбить на основной процесс связывания плюс множество собственных процессов плагинов, которые мы можем отключить, настроить или расширить. Это означало, что внешнему коду разрешалось подключаться к процессу связывания в определенных точках, из которых они могли выбирать (так называемые перехватчики).
Таким образом, плагины влияют на вывод и как бы расширяют возможности компилятора webpack.
Загрузчики работают на файловом уровне . Они могут написать шаблон, обработать некоторый код для его преобразования в зависимости от вашего удобства и т. Д.
Плагины работают на системном уровне . Они могут работать с шаблоном, обработкой файловой системы (имя, путь) и т. Д.