Comments 28
У меня типовой кейс — взять некоторый index.js, подтянуть все его зависимости, сложить вместе с учётом топологической сортировки (попутно выпилив код подключения зависимостей), минимизировать.
Я тестил Parcel, когда он еще не умел в ESM, и именно по этой причине, не смотря на привлекательность концепции, я не стал его использовать. Видимо, настало время дать ему второй шанс.
Проблема всех zero-configuration инструментов (а Parcel себя позиционирует именно так) в том, что или у вас в проекте строго то, на что рассчитывали авторы Parcel, или вам придётся натягивать сову на глобус (менять свой проект или дописывать в Parcel код для обработки именно вашего случая).
Чудес не бывает, zero-configuration работает только тогда, когда предположения сторон друг об друге полностью сходятся.
Если надо бандлер без дикого груза обратной совместимости и прочей монструозности — есть rollup. Его конфигурировать надо, но типичные кейсы конфигурируются крайне просто и коротко. И всегда остаётся возможность законфигурировать что-то совсем даже не типичное.
Затем, что мне проще написать скрипт на ноде для сложных случаев, с гораздо более широкими возможностями, чем ковыряться в конфигах, обертках и чужих API. И, в этом контексте, гораздо приятнее работать с минималистичными специализированными инструментами на каждом из этапов. Rollup вполне подходит (именно его я и использую сейчас), но почему бы не попробовать альтернативу?
Может мне в «этом» проекте надо es5, а в «другом» es6?
Пользуюсь в основном vue, а в нём webpack. Для простеньких сайтов хотел задействоваь как раз parcel, но задач таких пока что нет. Недавно на работе проводил лекции про сборщикам, искал разные, сперва нашёл brunch, но в нём не понятно, как сделать autoprefixer вместе с scss, я смог только раздельно. Потом нашёл Parcel, но и он оказался не без конфигов — для нормального async/await потребовался .babelrc, и какая-то настройка в .postcssrc, наверное для автопрефиксера как раз. И ещё такую багу заметил, что в live режиме он с первой правки код обновляет, а дальше нет, пробовал на разных компьютерах, но с одним и тем же кодом с модулями и await, он просто не видит моих изменений.
Не так важно, чьи это конфиги, но их пришлось писать.
Нужно прописать список поддерживаемых браузеров в формате browserslist, все остальные инструменты это подхватят и не будет ни префиксов, ни транспиляции
webpack.config.js, либо выносить наружу в стандартные конфиги, хоть вместе, хоть по отдельности. Не вижу смысла об этом спорить.Я все же оспаривал с тезис про обязательность отдельных внешних конфигов в отличных от parcel js-бандлерах: это неправда как минимум для webpack, там все можно уложить в общий конфиг, с единым синтаксисом.
где вы увидели здесь такой тезис.
.babelrc и .postcssrc — это не конфиги parcel, их и при использовании других сборщиков _надо_ писать (в дополнение к конфигу самого сборщика).(с)
ВСЁ не уложись в конфиг вебпака
Из перечисленного:
husky, судя по документации, укладывается в и так существующий
package.json, что логично, ибо к сборке он не относится.Это всё.
От того, что вы перенесли конфиги этих инструментов в конфиг вебпака, они не перестают быть конфигами
Что вы понимаете под конфигом вебпака, если не конфигурацию его лоадеров и плагинов?
Расскажите-ка мне о поддержке различными редакторами этих конфигов.
Может лучше свежий анекдот? Или любую другую информацию, которая так же не относится к теме обсуждения.
Сам по себе babel — не лоадер и у него есть свой конфиг
Невероятно, но факт: конфигурацию мы можем писать только для лоадера, этого достаточно.
Если конфиги будут в отдельных файлах, то редакторы кода их охотно подхватывают
Это позволяет вам заявлять, что конфигурировать можно исключительно через отдельные файлы? Пожалуй, стоит это оговаривать изначально, чтобы не оправдываться потом.
В общем-то, в чем основная суть parcel'а — он самостоятельно устанавливает нужные плагины для разных расширений файлов. Добавил, к примеру, .ts файл — сборщик тут же установил пакет для тайпскрипт. Не нужно его перезагружать и что-то там дописывать в конфигах. Для простых проектов штука реально классная!
Но он пока ещё слишком сырой. К примеру, девелоперский веб сервер не способен понять, что "./index.html" файл нужно отдавать по запросу "/", если хостишь всю папку.
Ну и для не самых частых юзкейсов всё равно придётся писать конфиги.
Помимо всех плюсов, которые даёт этот восхитительный бандлер, есть парочка минусов, которые в статье не были упомянуты:
- как только нужно подключать различные zero-runtime библиотеки (styled-components или linaria, например), требуются плагины, настроить которые с первого раза не получится. Хорошо, если получится со второго, а не с десятого.
- иногда бывают проблемы, когда ломается файловый кэш и приходится его руками удалять, а иногда полностью переустанавливать все зависимости
- бывает, что если в вашем коде была ошибка во время первой сборки
parcel index.html, то всё сломается (в папку dist попадет корявый код), и придется заново перезапускать весь parcel. - parcel для node js иногда ведёт себя странно, не всегда запихивая зависимости в собранный файл. Поэтому будьте осторожны с этим, особенно, если деплоите на хероку — код, который работал локально может сломаться.
И всё же, это лучший бандлер (по моему скромному мнению, не претендующему на истинность) для проектов средней и малой величины. Для домашних проектов точно стоит использовать именно его.
Parcel — мой любимый сборщик проектов