Сегодня для каждого фронтенд-инженера веб-пакет стал базовым навыком. Он в основном выполняет всю работу по локальной разработке, компиляции и сжатию, а также оптимизации производительности. С этой точки зрения веб-пакет действительно великолепен. Его рождение Это означает, что стал популярен целый набор инженерных систем, а автоматизация фронтенда постепенно унифицируется, так что фронтенд-разработка полностью распрощалась с прежней эпохой подсечки. Теперь webpack предназначен для фронтенд-разработки, точно так же, как gcc/g++ для C/C++, это инструмент, который вы не сможете обойти, несмотря ни на что.

Но даже при таком величии есть огромная проблема, и этоwebpack так сложно использовать! ! !

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

В качестве простого примера, простейший проект скаффолдинга, сгенерированный vue-cli, имеет целых 14 файлов, связанных с разработкой и построением, а код превышает 800 строк, а в реальном проекте будет только больше:

Итак, поскольку заголовок этой статьи «Почему так сложно использовать веб-пакет?» ", то давайте разберем фундаментальные причины, по которым здесь трудно использовать webpack.

Во-первых, документация крайне несовершенна.

Да, именно поэтому это было в первую очередь.

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

недружественный к пользователям

Например, можно сказать, что система плагинов веб-пакета является основной функцией веб-пакета, В основном, при построении проекта большинство задач выполняется с помощью различных плагинов. Однако в официальной документации есть всего несколько предложений о внедрении плагинов:webpack · Plugins, и даже рекомендую сразу перейти к исходному коду webpack:

Что еще хуже, большая часть существующей документации (включая документацию для некоторых плагинов веб-пакетов) говорит вам:Ты можешь это сделать", не объясняя"зачем тебе это нужно" а также "Каковы последствия этого".

Например, в целевой конфигурацииофициальная документацияВ нем перечислены цели, на которые вы можете строить, напримерnode,node-webkit,electron-main, но все они представляют собой простое предложение:

Хотите знать, что цельelectron-mainЧем он отличается от упаковки среды браузера? Извините, официальная документация не хочет вам говорить, смотрите исходный код или ищите в stackoverflow.

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

Вот почему при использовании webpack часто возникают следующие три философских вопроса:

Это проблема с вебпаком?
Как я могу решить эту проблему?
Эй, как я это решил?

Недружественный к разработчикам

Как мы разрабатываем плагин для веб-пакетов?

В официальной документации что-то написано оКак разрабатывать плагиныруководство. Но это руководство имеет только проходной уровень 60. Оно знакомит вас с основными примерами, основными понятиями и некоторыми API-интерфейсами плагинов веб-пакетов, но когда вы читаете этот короткий документ, вы действительно хотите разработать плагин самостоятельно. что то, что говорится в документации, действительно далеко не достаточно.

Давайте посмотрим, как написаны зрелые плагины в экосистеме веб-пакетов, чтобыhtml-webpack-pluginНапример, это плагин, широко используемый для создания html-файлов. В его исходном коде вы обнаружите, что он ссылаетсяПять плагинов, которые поставляются с webpack(Исходный код здесь):

var NodeTemplatePlugin = require('webpack/lib/node/NodeTemplatePlugin');
var NodeTargetPlugin = require('webpack/lib/node/NodeTargetPlugin');
var LoaderTargetPlugin = require('webpack/lib/LoaderTargetPlugin');
var LibraryTemplatePlugin = require('webpack/lib/LibraryTemplatePlugin');
var SingleEntryPlugin = require('webpack/lib/SingleEntryPlugin');

Ага? Для чего используются эти пять плагинов?

В официальной документации ни слова о встроенных плагинах, да, дажеPluginsЗдесь нет.официальная викиВыше было написано, но действительно слишком кратко, и похоже, что давно не обновлялось.

Давайте рассмотрим еще один столь же часто используемыйuglifyjs-webpack-plugin, он не зависит от встроенных плагинов webpack, но также ссылается на два файла внутри webpack:

import RequestShortener from 'webpack/lib/RequestShortener';
import ModuleFilenameHelpers from 'webpack/lib/ModuleFilenameHelpers';

В документации также нет информации об этих двух файлах. Хорошая вещь (?) заключается в том, что эти два файла, судя по именам файлов, являются, по крайней мере, библиотеками методов (на самом деле они есть) и не слишком сложны в использовании.

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

2. Чрезмерная система плагинов

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

Но у системы плагинов тоже много проблем.

количество плагинов

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

Или возьмем в качестве примера стандартный сгенерированный vue-cli проект скаффолдинга, всего имеется 7 сторонних плагинов:

"copy-webpack-plugin": "^4.0.1",
"extract-text-webpack-plugin": "^3.0.0",
"friendly-errors-webpack-plugin": "^1.6.1",
"html-webpack-plugin": "^2.30.1",
"webpack-bundle-analyzer": "^2.9.0",
"optimize-css-assets-webpack-plugin": "^3.2.0",
"uglifyjs-webpack-plugin": "^1.1.1",

и 7 встроенных плагинов webpack:

HashedModuleIdsPlugin
ModuleConcatenationPlugin
CommonsChunkPlugin
DefinePlugin
HotModuleReplacementPlugin
NamedModulesPlugin
NoEmitOnErrorsPlugin

Всего плагинов 14. Рассчитываем по среднему, что один плагин содержит 2-3 элемента конфигурации (это уже мало).На 14 плагинов более 30 конфигураций.Это уже современная разработка и построение вебпака .Самая базовая конфигурация, реальный проект будет только больше.

Обратите внимание, что 30+ элементов конфигурации намного сложнее, чем 30 строк кода.Поскольку элементы конфигурации уже имеют относительно высокий уровень абстракции, побочные эффекты конфигурации намного больше, чем одна строка кода. Например, для извлечения общедоступных модулей часто используется следующее:CommonsChunkPluginКонфигурация:

new webpack.optimize.CommonsChunkPlugin({
    name: 'app',
    async: 'vendor-async',
    children: true,
    minChunks: 3
})

Если вы не ветеран веб-пакетов, вы должны быть сбиты с толку, увидев эти 4 конфигурации:

nameЧто я должен заполнить? Вы можете назвать это как хотите?
asyncчто это? Асинхронные модули? Так почему же это строка?
childrenчто это? Почему нетArrayноboolean?
minChunksЧто это за номер?chunkЧто это?

Тогда вы идете, чтобы увидетьДокументация для CommonsChunkPlugin, после пятнадцати минут напряженного чтения вы обнаружите, что эти четыре конфигурации непросты, и каждое изменение будет иметь большое влияние на сборку.

Плохая новость заключается в том, что таких мест в проекте более 30!

Итак, каждый раз, когда я меняю сборку проекта, это в основном так:

Плагины, ориентированные на конфигурацию

Прежде чем обсуждать эту тему, ответьте на два вопроса:

Влияет ли порядок плагинов webpack на результат сборки?
Если порядок плагинов другой, что это повлияет?

На самом деле, я искал официальную документацию по этим двум вопросам и не упомянул, на что повлияет порядок плагинов, но я нашел вопрос на stackoverflow:Webpack: Does the order of plugins matter?

Итак, ответ:Порядок плагинов влияет, но роль неизвестна.

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

Что вызваноориентированный на процесс? Если вы знаете или использовали gulp, инструмент автоматизации, вы должны помнить концепцию gulp pipe, то есть получать исходные данные (исходный код js/css/html, изображения, шрифты и т. д.) из источника, а затем комбинировать данные один за другим Конвейер, окончательный вывод становится результатом сборки. В псевдокоде это выглядит так:

gulp.src('某些源文件')
    .pipe(处理一)
    .pipe(处理二)
    .pipe(处理三)
    .dest('构建结果')

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

Однако, если это веб-пакет, это будет выглядеть так:

{
    plugins: [
        插件一,
        插件二,
        插件三
    ]
}

Здесь плагины 1, 2 и 3 полностью ориентированы на конфигурацию и не сообщают вам о каком-либо порядке выполнения, они могут срабатывать в любой точке сборки вебпака, и вы можете только примерно догадываться, с какого момента времени он работает. их функциональность. Вот почему изменение некоторых конфигураций веб-пакетов похоже на развязывание кабеля наушников, который долгое время лежал в сумке, что хлопотно и раздражает.

Конечно, у таких настраиваемых плагинов есть и преимущества: Configurable представляет собой высокий уровень интеграции.Когда у вас всего 1-3 плагина, умственная нагрузка на поддержание этих конфигураций приемлема и намного дороже, чем поддержка конфигураций, ориентированных на процессы. удобный.Но когда количество плагинов превышает это значение, сложность сборки увеличивается в геометрической прогрессии., как мы упоминали ранее, современный проект веб-пакета будет иметь как минимум плагины 14 и как минимум конфигурации 30. В этом случае ориентированность на процесс лучше, чем ориентированность на конфигурацию, поэтому я всегда чувствую, что gulp + webpack является причиной правильное решение.

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

3. Является ли конфигурация серебряной пулей?

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

В мире технологий конфигурация также полезна. Многие инструменты утверждают, что они полностью настроены. Пока вы добавляете файл конфигурации в свой проект, этот инструмент может помочь вам сделать очень многое.babel,eslint,stylelint, а также webpack, обсуждаемый в этой статье.

Так является ли конфигурация концом эволюции всех инструментов? Решает ли это все проблемы?

В программной инженерии есть известная поговорка: «нет серебряной пули", ОтноситсяСложные проблемы разработки программного обеспечения не могут быть решены простыми ответами. В вопросе фасадного инженерного строительства он не является исключением.

Как решить строительство front-end проектов? Ответ, данный webpack:С помощью веб-пакета + загрузчика + плагина сделайте все сборки ресурсов настраиваемыми.Это очень мощно в эпоху, когда она родилась.Простой файл конфигурации может помочь вам решить все проблемы построения ресурсов.

Однако с течением времени построение фронтенд-проекта становится все более и более сложным, конфигурация веб-пакета становится все более и более сложной, а его обслуживание становится все более и более сложным.create-react-app,vue-cliТакие инструменты создания шаблонов дополнительно инкапсулированы на основе веб-пакета, чтобы помочь вам автоматически генерировать конфигурацию веб-пакета. В настоящее время веб-пакет стал более «низкоуровневым» инструментом, и эти леса — ваши настоящие «инструменты сборки» или,Конфигурация, предоставляемая этими каркасами, является вашей реальной конфигурацией сборки..

Почему это происходит?

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

Итак, теперь мы можем ответить на заголовок этого абзаца: является ли конфигурируемость панацеей от сложности? Конечно нет, потому чтоПо мере увеличения сложности конфигурация будет постепенно усложняться, а обслуживание будет становиться все сложнее, пока не превысит некое критическое значение, потребуется ее дальнейшая инкапсуляция на ее основе для генерации новой конфигурации.

В-четвертых, будущее передового инженерного строительства

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

В древние времена фронтенда нам не нужно было строить, потому что фронтенд проект в это время был еще очень прост, и исходного html/js/css хватало для удовлетворения потребностей, и это было удобно и быстро обрабатывать эти ресурсы вручную.
С усложнением интерфейса эффективность ручной обработки становится все ниже и ниже, и появились автоматические инструменты, такие как grunt и gulp, которые экранировали многие детали обработки ресурсов, чтобы обработка ресурсов могла выполняться автоматически.
С появлением все большего количества процессов конструирования, все большего количества типов ресурсов, более сложных языковых функций ECMAScript и начала различать среды разработки/тестирования/производства такие инструменты, как gulpfile/grunt, больше не могут удовлетворять наши потребности. полный набор решений для построения конфигурации, и webpack является таким решением.
По мере того, как конфигурация веб-пакета становится все более и более сложной, стоимость обслуживания также становится все выше и выше, поэтому появилось много инструментов для формирования шаблонов, которые помогут вам создать конфигурацию веб-пакета и инкапсулировать сложность веб-пакета.

затем будущееИнструменты сборки интерфейса нового поколенияНа что это похоже?

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

Больше встроенных функций, таких как babel, dev-server, HMR, sourceMap и т. д.;
Меньше конфигурации или даже нулевая конфигурация;
Различайте среды разработки, тестирования и производства по более низкой цене;
Лучшая производительность, интеграция длительных процессов сборки, поддержка многоядерных процессоров и т. д.;
Поддержка новых типов модулей: асинхронные модули, модули WebAssembly и др.

По сути, это частьЧто нового в вебпаке 4.0, и видел некоторое время назадparcelТакже имеет некоторые из этих функций (хотя сейчас это кажется очень незрелым). Количество таких инструментов сборки в будущем будет только увеличиваться.

Суммировать

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

Почему webpack так сложно использовать? Ответ, данный в этой статье, сводится к двум пунктам:

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

Решатся ли эти проблемы в будущем? Конечно. На самом деле, эта статья действительно подозревается в том, что она является заголовком, и более точным заголовком должен быть:

"настоящее времяПочему webpack так сложно использовать? 》

Из-за проблем, упомянутых в этой статье, все они будут исправлены в webpack 4.0.

Эээ... Что касается его документации... Забудь, забудь О__О "...