Comments 19
Меня давно уже стала напрягать вся эта портянка в конфиге webpack, я просто отказался от него в пользу Rollup, а теперь Vite. Проще стало конфигурировать, много полезных дополнений и будь то Vue, React или просто приложение на vanilla сборка проходит быстро и четко.
Приходишь на проект, а там вместо православного вебпака какой-то Витя. Пилителям лендосов конечно не сидится ровно, дело жизни вместо двух строчек конфига написать одну, но все остальные вебпак конфигурируют раз в 2-3 года, а то и реже.
Не, знаю, насчёт лендосов. Они там неплохо и на jQuery силами самих верстальщиков собираются, с scss-ом.
Но насчёт vite для среднестастияеского интернет-магазина с грудой typoscript, неплохой сборщик.
Стартует на дев-машине быстро. Все что нужно - лоадит. SSR к Vite скоро начнем постигать на проде. Это явно речь не о лендосе уже.
Webpack Encore от Symphony ещё куда ни шло. И портянки перестали быть чем-то необходимым. Скорость: на дев-машине - проект среднего размера пересобирался очень долго. С Vite эти проблемы перестали существовать. Кмк, может я не разбираюсь, и webpack тоже может за мгновение стартовать сборку всю на дев.
Вы не пробовали storybook - к Vite подключается ?
Можете конфигурацией поделиться?
emotion или styled components под Vite работают ?
Eslint - там тоже есть ?
В текущей реализации проекта (без SSR) конфиг выглядит так: https://paste.slave.dimti.ru/?0e723a34823f8d4e#57wQbHT6bCMaggTb31F6th1N7AfF9z9MXET4LDjgCBVy. Мой коллега Александр подключил туда Vue и небольшой минификатор изображений.
Eslint лежит рядом: https://paste.slave.dimti.ru/?8abe3f83b6f8a93e#DdswMt6FgQdYc9894JpsEieKK9nDk7vsQ6sFJGJZWDiL
Видимо Eslint сам по себе цепляется (у меня к IDE прицеплен, но насчет сборщика я не уверен). Позову помощь.
Большое спасибо!
Конфигурация выглядит не намного меньше такой же webpack :)
Это да. По сравнению с ними - webpack encore выглядет минималистично: https://paste.slave.dimti.ru/?9b7c06089ea6c5b6#3b4WyKt8hNn1KVAEoQPM9dfpTTfKre5fXHw9gBuY7RVS
Начали смотреть в сторону storybook, говорят у него родная интеграция с Vite. Только до конца не уверены нужно ли это нам. Я во фронтенде не очень силен (как показала череда недавних собеседований на позицию Fullstack: я, оказывается, не знаю ES6 и flex-wrap) - поэтому искренне не могу вовлечся во все новые техники, применимые к проекту по части nodejs. Может это конечно и есть "проклятие" фуллстеков, что они не могут как следует вовлечся в какую-то одну область.
Я для PoCов и мелких проектов ушёл на esbuild. Скорость сборки в дев-режиме оооочень приятная, как и размер зависимостей. Конечно, когда подключаешь линтинг, tsc-чек, компрессию, tailwind постпроцессинг и всё прочее, то падает, но всё равно остаётся в разы быстрее вебпака.
Тем не менее, когда уходит в прод - делаю вебпак-конфиг, из соображений, что народ уже писал: чтоб стандартный дев разобрался.
Вот здесь https://habr.com/ru/post/506636/ описывал намного более продвинутый вариант конфигурирования - конфиг вебпака протипизирован TS, разбит по папкам, файлы в которых имеют семантичные имена. Также там описан отличный вариант проброса env-параметров, рецепт параллельной сборки для фронта и для сервера, запуск сервера после билда.
Но даже тот вариант уже подустарел. А непротипизированное решение с webpack --build вместо билд-файла и продуманности системы файлов, колбеков и переменных - это просто самый первый и очевидный шаг к построению вебпакового конфига.
Но за статью плюс - часто маленькие шаги лучше принимаются и применяются сообществом, что вдохновляет задумываться и улучшать свои подходы к кодированию.
Когда вы выносите часть код в отдельную библиотеку вы только добавляете +Х к сложности своего проекта. Эту новую зависимость нужно поддерживать, версионировать, делать регресс при изменениях. Для части проектов этот конфиг избыточен, для части он недостаточек. И вообще, мы не серьезно говорим о том, чтобы вынести конфиг в отдельный репо, Карл? :-)
Выносить в отдельную библиотеку имеет смысл если у вас много проектов, имеющих примерно один и тот же стек и условия сборки. Понятное дело, что если проект один или несколько это не имеет большого смысла и пойдёт только во вред, но когда их количество приближается к десятку или переваливает за это значение, то такой подход более чем имеет право на существование. Для нового проекта не придётся копипастить конфиги на старте - достаточно будет установить одну зависимость. Также не придётся вносить изменения во все проекты, если вдруг необходимо будет обновить одну из зависимостей. При этом, если на каком-либо из проектов не захочется вот прямо сейчас обновлять и поддерживать новую версию (если она вдруг потребует дополнительных изменений), то всегда можно зафиксироваться на текущей версии. Все издержки по версионированию ложатся на npm. А поддержка и регресс ничем не будут отличаться от того как если бы эти конфиги были непосредственно в самом проекте.
Тут есть одна ловушка. На одном проекте был похожий сетап, скрипты сборки, подключаемые как сабмодули + локальный конфиг, но не суть, идея та же. Было десятка два-три репозиториев микросервисов (условно), которые пользовались этим централизованным решением.
Так вот, после определённого порога накопленные специфические для конкретного проекта требования становятся комбинаторным взрывом. Слишком много опций сборки, поддержки специальных параметров конфига, эдж-кейсов, комбинаций настроек. Особенно когда есть просто сборки, дев-сборки, тестовые, а/б, условные фича-тоглы, экспериментальные проекты с нечеловеческими конфигами и т.п.
Ну то есть идея имеет право на жизнь, но ниша её не очень широка и обставлена дополнительными условиями, типа длительного неизменного мейнстрима.
Никто не мешает вынести общее ядро, а кастомные плагины и лоадеры дописывать уже в конкретных проектах, расширяя дефолтный конфиг. Не обязательно в него запихивать все, если конкретная фича нужна только в одном из десяти проектов.
Если проект экспериментальный - то делать полностью свой конфиг.
Да как и везде - вопрос баланса и здравого смысла.
Никто не мешает вынести общее ядро, а кастомные плагины и лоадеры дописывать уже в конкретных проектах, расширяя дефолтный конфиг
В итоге вы тратите время на анализ и поддержку этого общего / частного. Вы занимаетесь чем угодно, но не разработкой проекта.
Никто вам не мешает начинать проекты на основе шаблона, т.н. scaffolding, иметь некую базу шаблонов сборки. Это более здравая мысль, нежели искать общее и частное, поддерживать непонятный репо и версионировать его.
можно webpack.config.mjs и отказаться от require в пользу import. Если в проекте модули. Конфиг из статьи похож на легаси webpack4
Использую webpack-merge: https://github.com/SuhushinAS/react-starter-kit/blob/master/webpack.config.js
На своих проектах я запилил конфиг Webpack-а, используя паттерн "Строитель". Строк кода, может быть и больше, чем лапша на if-ах, но зато всё по полочкам и понятно что происходит.
Спасибо за идею вынести всё в отдельных npm-пакет.
Децентрализованная конфигурация webpack или как упростить сборку проекта