Комментарии 68
Давайте по порядку.
Откуда вы их взяли?
Из официальной документации и, самое главное, из документации Babel и PostCSS. Знаете как использовать — используйте. Не знаете — почитайте, попробуйте. Никто же не заставляет :)
Такое ощущение что в мире js ничего не имеет конфигов по умолчанию, нельзя просто сделать install и запустить всё на стандартных настройках
Можно, больше Вам скажу — на главной странице пример, который не требует ни одного конфига для Babel или PostCSS. Если они Вам не нужны — не пишите. Тут сыграло роль то, что статья носит чисто информативный характер, и если в нее вставить еще более простой пример, то Вы никак не увидите его главный плюс, заключающийся в отсутствии необходимости писать даже маленький сферический webpack.config.js
И в этом плане Parcel не выглядит чем-то сильно удобнее. Всё те же конфиги (у каждого свои), магия расположения папок, и необходимость несколько дней курить документацию для того чтобы сделать всё осознанно а не тупо скопировать команды как обезьяна.
Так в статье нет ни одного конфига для самого Parcel :)
Хотите LESS — импортируйте .less файл и он добавится в бандл. Хотите VueJS — импортируйте в бандл. Суть в том, что вы скармливаете в Parcel некую точку входа. Он начинает анализировать ее вглубь, строя дерево зависимостей. Поэтому, если в ваш импорт попадает тот или иной файл — он оказывается в итоговом бандле.
Возможно, я слишком вскользь упомянул это в данном абзаце:
У нас есть сущность — Asset. Ассет — это любой файл. Механика работы такова: реализуется интерфейс, который предоставляет логику для превращения файла в AST, разрешения всех зависимостей, применения нужных трансформаций и генерирования итогового кода.
CSS не нужно тянуть через JS, Вы можете импортировать его через другой CSS файл, подключить в HTML или, опять же, в JS. Пример использовал так называемые CSS Modules для наглядной демонстрации того, что в вебпаке потребовало бы конфигурации.
Свой сервер вы можете поднять, насколько я знаю, если хотите — я могу найти, как это сделать. Но опять же, я не предполагал, что к данному инструменту возниктнет так много базовых вопросов, ведь это обзорная статья, а не туториал.
Подводя итог — попробуйте создать обычный HTML, подключить в нем SCSS в теге <style>
и свой JS-файл в теге <script>
, в котором докиньте Vue и запустите команду parcel index.html
. И все, никаких CSSinJS и прочего.
Не за что, рад что стало немного яснее :) Надо вынести в статью информацию о том, как происходит разрешение зависимостей.
Есть плагин
Сейчас сам пишу плагин для Pug. Кода немного, раздумываю, стоит ли написать ради этого статью с объяснением работы.
Ну базовая механика в нем ровно такая же как в вебпаке, удобство только для старта, но всегда есть yeoman. Почти уверен что для более-менее сложной конфигурации если он и позволит настроить так же гибко как вебпак, то будет выглядеть не менее монструозно. А вот скорость работы действительно радует, даже интересно насколько это правда (думаю, что на больших проектах не очень банально по той причине, что скорость компилирования бейбеля не зависит от сборщика, а кеш и в вебпак завезли).
Согласен, но тут конечно вся прелесть в том, что инструмент из разряда «поставил, нажал, заработало». Примерно так же многий софт под macOS позиционируется :) Данный принцип здорово подходит, когда тебе не нужно искать шаблон для yeoman (или писать свой), а просто надо в полпинка запустить окружение и делать разные клевые штуки. Возможности вебпака больше, это бесспорный факт.
Данный принцип здорово подходит, когда тебе не нужно искать шаблон для yeoman (или писать свой), а просто надо в полпинка запустить окружение и делать разные клевые штуки.
Да, тут не поспоришь. Хоть я и в состоянии написать сколь угодно громоздкий конфиг вебпака, всегда когда нужно быстро на коленках собрать и проверить mvp один и тот же геморрой с boilerplate, которые частично не работают/слишком переусложнены/устарели и прочее.
Глубоко не копал, но все же — вот у меня есть тесты на карме, которые в кармаконфиге инклудят конфиг вебпака. Можно это завести тут и как вообще в parcel дела с тестами обстоят?
В официальной документации на этот счет ничего нет, поэтому скорее всего по старинке, ручным запуском команды. Но можно копнуть в сторону запуска Parcel через его экземпляр, как показано в этом примере внизу
Да проблема не в том, как запустить тест через Parcel, а как к карме подцепить конфиг парселя, чтобы файлы корректно парсились, например, импорт svg.
Как это вообще можно настроить в parcel — непонятно: вроде есть ключ --public-url, но он работает некорректно.
Здесь посмотрите :)
Пришлось форкнуть и внести изменения под свой проект.
Я не знаю, зачем и что Вы форкали, потому что команда
parcel build src/content.pug -d build/ --public-url ./
генерирует такой вывод:
<html><head><link rel="stylesheet" href="4a0e5b1da5011b82b932acfe8650e4a8.css"></head><body><h1>Test extends</h1><script src="4a0e5b1da5011b82b932acfe8650e4a8.js"></script></body></html>
Так в 2017 для настройки всего этого специальный человек нужен — frontend build engineer.
А фронтендер — пишет компоненты на реакте.
Но ничего не верстает, для этого тоже отдельный человек.
На мой взгляд теряется смысл различных связках boilerplate + webpack…
Всё правильно vlreshet говорит, вечные конфиги, rc-шки, соглашения и другие тайные занания. Почему никто не задумывается о another-awesome-bundler init
, который бы сам задетектил jsx
, ts
, less/sass/postcss
и сконфигурил бы как надо? Хочешь продвинутой конфигурации, не вопрос another-awesome-bundler eject
, create-xxxx-app
ведь создали, тут-то что мешает?
Я думаю дело в том, что комплексные и сложные проекты проще поддерживать, имея свой конфиг. Его можно вертеть и так, и эдак, кидать лоадеры и плагины из гитхаба (форки с доработками, например) и так далее по списку. Посмотрите репозитории angular-cli, react-create-app и их аналоги — все просят дать возможность расширять коробочные конфиги и так далее
vampireos@home:~/parcel-test$ parcel index.html
parcel: команда не найдена
эм… как так та?) Ведь всё установилось же
vampireos@home:~$ yarn global add parcel-bundler
yarn global v1.3.2
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.1.3: The platform "linux" is incompatible with this module.
info "fsevents@1.1.3" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Installed "parcel-bundler@1.2.0" with binaries:
- parcel
Done in 12.12s.
или ему очень нужна эта штука info fsevents@1.1.3: The platform «linux» is incompatible with this module.
Судя по логу ярна — все в порядке. У Вас корректно выставлена переменная PATH?
yarn config list
и export | grep " PATH="
.vampireos@home:~/parcel-test$ yarn config list
yarn config v1.3.2
info yarn config
{ 'version-tag-prefix': 'v',
'version-git-tag': true,
'version-git-sign': false,
'version-git-message': 'v%s',
'init-version': '1.0.0',
'init-license': 'MIT',
'save-prefix': '^',
'ignore-scripts': false,
'ignore-optional': false,
registry: 'https://registry.yarnpkg.com',
'strict-ssl': true,
'user-agent': 'yarn/1.3.2 npm/? node/v6.11.4 linux x64',
lastUpdateCheck: 1513089669001 }
info npm config
{ prefix: '/home/vampireos/.npm-global' }
Done in 0.05s.
vampireos@home:~/parcel-test$ export | grep " PATH="
declare -x PATH="/home/vampireos/.npm-global/bin:/home/vampireos/.npm-global/bin:/home/vampireos/.npm-global/bin:/home/vampireos/.npm-global/bin:/home/vampireos/.npm-global/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:yarn global v1.3.2
yarn add parcel-bundler
yarn parcel index.html
Ставить что-то глобально — дурной тон.
Простите, я с наивным вопросом: а почему инструменты для работы с JS тоже пишут на JS? Ведь это тянет за собой кучу проблем, которые приходится как-то решать ("использует worker process для многопоточной сборки" — весьма жирный намёк).
Неужели только желание оставаться в рамках одного языка?
Я понимаю ограничения в браузере — на юзерском компе что-то другое не вдруг выполнишь. Понимаю на сервере (хотя там другие скриптовые языки тоже используются). Но почему инструменты разработки делаются на том же языке?
P.S. В принципе, эта картина характерна не только для JS, но для него особенно заметна.
"использует worker process для многопоточной сборки" — весьма жирный намёк
Намек не очень понятный. Что именно здесь не так?
Никакого "не так" здесь нет. Напротив, очень правильное решение.
Но многопоточность — не конёк JS (и это, в общем-то, нормально для его ниши и понятно в условиях ограничений, накладываемых браузером). В других языках она поудобнее, имеет больше возможностей, не имеет таких пенальти по быстродействию (обычно ценой меньшей безопасности — что приемлемо в данном случае).
В других языках она поудобнее, имеет больше возможностей
Вот это очень спорное утверждение. Не вижу каких-то киллер-фишек, ради которых нужно тащить другой язык.
Зато есть анти-пример. По историческим причинам, node-gyp, использующийся для сборки нативных модулей, зависит от python, что причиняет немало трудностей при запуске в контейнерах и других минималистичных окружениях.
Гораздо удобнее работать, когда все написано на едином языке и ничего лишнего ставить не надо, кроме движка для этого языка.
Текстовый редактор у вас написан на JS? Оконный менеджер? Операционная система?
Ну, вы поняли: когда речь идёт не о части вашего кода, а об инструменте для работы с этим кодом — удобнее уже собранный бинарник, и язык, на котором написаны его исходники, неважен.
К системе сборки приходится чаще писать плагины и обертки, чем к оконному менеджеру.
Поэтому исходники на знакомом языке и дружелюбное API на JS лишними не будут.
1. Работаю с vue компонентами, парсель пока не поддерживает. Впрочем должно быть скоро имплементировано (https://github.com/parcel-bundler/parcel/issues/5). Но вопрос больше глобальный, как работать с фреймворком «х», если он требует дополнительного парсинга? И если начать поддерживать все фреймворки, то останется ли он таким быстрым? Или же нужно будет опять-таки конфигурировать?
2. Я не увидел из доументации, что там с хэшами для js и css файлов? Добавляет ли он их автоматически. Зачастую бывает необходимо выгрузить хэши в json, чтобы потом бэкенд мог из использовать.
3. Можно ли использовать алиасы и дополнительные плюшки, как то `webpack.DefinePlugin`.
4. Уверен, что для определённых юзкейсов размер сборки будет не оптимальным. Как дебажить и оптимизировать (a-la `webpack-bundle-analyzer`)?
1) JS он отдает бабелу, а там через плагины можно обвязку сделать
2) Автоматически создает хэши и кладет файл sha.json со всеми хэшами
3) Можно использовать алиасы в бабеле, опять же
4) Пока такого нет, но думаю сделают :)
На самом деле я не пытаюсь разразить жаркую дискуссию, и даже тот факт, что моя компания инвестирует в вебпак тут не при чём :) Просто мыслю вслух могу ли я в своём проекте перейти на парсель. Ответ: пока нет. Слишком много надо будет кастомного допиливать пока. Обязательно буду следить за развитием проекта.
Я предполагаю, что решение сделать основную ставку на бабел (или постцсс) — это отличный способ избавится от своих собственных конфигов. По поводу вебпака — он его не заменит, только на простых проектах. Да и у него нет такой цели :)
grunt, gulp, webpack, rollup (наверняка, я что-то пропустил), и теперь вот parcel… ждем два года, и встречаем новый <убер-пупер-придумайте-название-сами> сборщик, который заткнет всё старое за пояс. И принесет дзен в мир фронтенда. Но не дольше, чем на два года.
Потому что мир не стоит на месте. Это прекрасно, что есть люди, желающие улучшить инструменты разработчика и предлагают новые решения.
Насильно вам их никто не навязывает, можно продолжать пользоваться старыми, если все устраивает
Да не вопрос, вот свежачёк microbundle (zero-configuration bundler for tiny modules), всего неделю назад вышел и уже 1.5K✰
Parcel — очень быстрый бандлер, не требующий настройки