Для чего
Parcel — маленький и быстрый бандлер, позиционируется как решение для маленьких проектов. С момента первого релиза (7 дней назад) уже собрал 8725 звездочек на гитхабе. Согласно официальной документации имеет следующие плюсы:
Быстрая сборка
Parcel использует worker process для многопоточной сборки, а так же имеет свой файловый кэш для быстрой пересборки при последующих изменениях.
Собирает все ваши ассеты
Из коробки имеется поддержка ES6, TypeScript, CoffeeScript, HTML, SCSS, Stylus, raw-файлов. Плагины не требуются.
Автоматические преобразования
Весь код автоматически проходит через Babel, PostCSS, PostHTML — подхватываются при необходимости из node_modules.
? Разделение кода без лишней конфигурации
Используя динамический import(), Parcel разделяет бандл для возможности быстрой начальной загрузки точки входа в приложение
Горячая перезагрузка
Типичный хот-релоад без конфигурации — сохраняете изменения и они автоматически применяются в браузере.
Дружелюбный вывод ошибок
При ошибке подсвечивается кусок кода, в котором она произошла.
Так же на главной странице приводится бенчмарк:
| Bundler | Time |
|---|---|
| browserify | 22.98s |
| webpack | 20.71s |
| parcel | 9.98s |
| parcel — with cache | 2.64s |
Механика работы
Подход Parcel схож с оным у Webpack (тут сложно придумать что-то новое).
У нас есть сущность — Asset. Ассет — это любой файл. Механика работы такова: реализуется интерфейс, который предоставляет логику для превращения файла в AST, разрешения всех зависимостей, применения нужных трансформаций и генерирования итогового кода. Если вас не устраивает работа какого-то ассета из коробки или вы хотите добавить свой — нет ничего сложного.
Дальше в дело вступает Packager. Упаковщик склеивает ассеты в итоговый бандл. Это происходит после обработки и успешного построения дерева. Упаковщики регистрируются на основе типа файлов. Хотите написать свой упаковщик? Вам сюда.
Так же мы можем писать свои плагины, которые Parcel будет подхватывать из package.json. Для этого у названия пакета плагина должен быть префикс parcel-plugin-. Но это уже совсем частный случай, который скорее всего уже ведет к тому, что надо переключаться на webpack или другой удобный инструмент.
На практике
Ставим пакет, инициализируем приложение через любой пакетный менеджер:
$ yarn global add parcel-bundler
$ mkdir parcel-test && cd parcel-test
$ yarn init -yДля примера напишем hello world на Preact. Создадим следующую структуру:
parcel-test
+-- package.json
+-- src
¦ +-- app.jsx
¦ +-- components
¦ ¦ L-- clock
¦ ¦ L-- Clock.jsx
¦ L-- index.html
L-- yarn.lock
3 directories, 5 filesА так же установим необходимые пакеты:
$ yarn add preact babel-plugin-transform-react-jsx postcss-modules autoprefixerДля того, чтобы сконфигурировать Babel создадим .babelrc со следующим содержанием:
{
"plugins": [
["transform-react-jsx", { "pragma":"h" }]
]
}Для PostCSS:
{
"modules": true,
"plugins": {
"autoprefixer": {}
}
}Для autoprefixer:
> 1%
last 2 versionsindex.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Parcel demo</title>
</head>
<body>
<script src="./App.jsx"></script>
</body>
</html>App.jsx
import { h, render } from 'preact';
import { Clock } from './components/clock/Clock';
render((
<div>
<h1>It works!</h1>
<Clock />
</div>
), document.body);Clock.jsx
import { h, Component } from 'preact';
import styles from './Clock.css';
export class Clock extends Component {
constructor() {
super();
this.state = {
time: Date.now()
};
}
componentDidMount() {
this.timer = setInterval(() => this.setState({ time: Date.now() }), 1000);
}
componentWillUnmount() {
cleanInterval(this.timer);
}
render(props, state) {
let time = new Date(state.time).toLocaleTimeString();
return <span className={styles.clock}>{ time }</span>
}
}Clock.css
.clock {
color: green;
}
И это все. Как можно заметить, мы не потратили ни минуты на написание конфигурационных файлов, за исключением .babelrc и .postcssrc
Подводя некий итог
Перед нами эдакий "Webpack на минималках", предоставляющий возможность быстрого развертывания рабочего окружения для небольшого проекта. Стек технологий по сути ограничен лишь стандартным набором ассетов, но в любой момент его можно расширить и своими собственными. С учетом полной поддержки Babel мы легко можем использовать практически любой другой фреймворк или библиотеку (разве что с Angular будут сложности, ведь писать с его помощью на ES6 и без родного инструментария — задача на любителя), а поддержка PostCSS из коробки является еще одним приятным дополнением.
Из неудобств я пока что могу отметить только одно — при работе с TypeScript бандлер не учитывает пользовательские пути и базовый каталог (секции baseUrl и paths), указанные в файле tsconfig, и, соответственно, не может нормально разрешать пути импортируемых модулей. На гитхабе идет обсуждение решения этой проблемы.
vlreshet
Уже который раз есть желание изучить все эти бандлеры, и каждый раз втыкаюсь в одни и те же 2 проблемы:
1. Во всех уроках/инструкциях/древних манускриптах есть строка типа «теперь просто ставим babel-plugin-transform-react-jsx postcss-modules autoprefixer something-fucking-js one-more-plugin againreactcssjsbullshit, и всё работает!». Но никто и нигде не говорит откуда брать эти списки модулей? Откуда вы их взяли? Что за postcss? Откуда новичку знать что нужно поставить а что нет? Где почитать об этих десятках модулей которые ставят для hello world на vuejs? Просто набор магии «напишите вот так и будет работать»
2. Потом так же «легко и быстро» пишут по 10 конфигов для всего на свете. Такое ощущение что в мире js ничего не имеет конфигов по умолчанию, нельзя просто сделать install и запустить всё на стандартных настройках (как в том же composer на php, где можно воообще без конфигурирования поднять hello world за 3 команды). Или другая крайность — «сделайте вот так, и мы всё сами скомпилим, запихнём вам в html, и будет вам счастье». А где оно появится в моём html, почему, как это можно изменить — непонятно.
И в этом плане Parcel не выглядит чем-то сильно удобнее. Всё те же конфиги (у каждого свои), магия расположения папок, и необходимость несколько дней курить документацию для того чтобы сделать всё осознанно а не тупо скопировать команды как обезьяна. В этом плане js уходит в какую-то тёмную степь, в том же java я за пару часов понял как поставить, запустить, и поправить проект с maven, имея околонулевый опыт в java.
P.S. Ох и выхвачу сейчас минусов, всё же «элементарно и понятно»
xxxTy3uKxxx Автор
Давайте по порядку.
Из официальной документации и, самое главное, из документации Babel и PostCSS. Знаете как использовать — используйте. Не знаете — почитайте, попробуйте. Никто же не заставляет :)
Можно, больше Вам скажу — на главной странице пример, который не требует ни одного конфига для Babel или PostCSS. Если они Вам не нужны — не пишите. Тут сыграло роль то, что статья носит чисто информативный характер, и если в нее вставить еще более простой пример, то Вы никак не увидите его главный плюс, заключающийся в отсутствии необходимости писать даже маленький сферический webpack.config.js
Так в статье нет ни одного конфига для самого Parcel :)
vlreshet
Открываем parceljs.org. Первая страница:
xxxTy3uKxxx Автор
Хотите LESS — импортируйте .less файл и он добавится в бандл. Хотите VueJS — импортируйте в бандл. Суть в том, что вы скармливаете в Parcel некую точку входа. Он начинает анализировать ее вглубь, строя дерево зависимостей. Поэтому, если в ваш импорт попадает тот или иной файл — он оказывается в итоговом бандле.
Возможно, я слишком вскользь упомянул это в данном абзаце:
CSS не нужно тянуть через JS, Вы можете импортировать его через другой CSS файл, подключить в HTML или, опять же, в JS. Пример использовал так называемые CSS Modules для наглядной демонстрации того, что в вебпаке потребовало бы конфигурации.
Свой сервер вы можете поднять, насколько я знаю, если хотите — я могу найти, как это сделать. Но опять же, я не предполагал, что к данному инструменту возниктнет так много базовых вопросов, ведь это обзорная статья, а не туториал.
Подводя итог — попробуйте создать обычный HTML, подключить в нем SCSS в теге
<style>и свой JS-файл в теге<script>, в котором докиньте Vue и запустите командуparcel index.html. И все, никаких CSSinJS и прочего.vlreshet
Спасибо за развёрнутый ответ! Теперь всё стало чуточку понятнее и parcel кажется действительно более удобным чем тот же webpack)
P.S. это не сарказм, реально спасибо.
xxxTy3uKxxx Автор
Не за что, рад что стало немного яснее :) Надо вынести в статью информацию о том, как происходит разрешение зависимостей.
vlreshet
Разобрался более подробно, затестил, забираю обратно свои слова:
Parcel — офигенская штука. Да, сейчас не всё работает, но судя по баг трекеру на гитхабе — прогресс идёт, надеюсь в будущем придёт и бОльшая популярность. Главное чтобы проект не забросили.
P.S. а не работают пока-что однофайловые .vue компоненты, так и не нашёл способа их запустить.
xxxTy3uKxxx Автор
Есть плагин
Сейчас сам пишу плагин для Pug. Кода немного, раздумываю, стоит ли написать ради этого статью с объяснением работы.
kahi4
Ну базовая механика в нем ровно такая же как в вебпаке, удобство только для старта, но всегда есть yeoman. Почти уверен что для более-менее сложной конфигурации если он и позволит настроить так же гибко как вебпак, то будет выглядеть не менее монструозно. А вот скорость работы действительно радует, даже интересно насколько это правда (думаю, что на больших проектах не очень банально по той причине, что скорость компилирования бейбеля не зависит от сборщика, а кеш и в вебпак завезли).
xxxTy3uKxxx Автор
Согласен, но тут конечно вся прелесть в том, что инструмент из разряда «поставил, нажал, заработало». Примерно так же многий софт под macOS позиционируется :) Данный принцип здорово подходит, когда тебе не нужно искать шаблон для yeoman (или писать свой), а просто надо в полпинка запустить окружение и делать разные клевые штуки. Возможности вебпака больше, это бесспорный факт.
kahi4
Да, тут не поспоришь. Хоть я и в состоянии написать сколь угодно громоздкий конфиг вебпака, всегда когда нужно быстро на коленках собрать и проверить mvp один и тот же геморрой с boilerplate, которые частично не работают/слишком переусложнены/устарели и прочее.
Глубоко не копал, но все же — вот у меня есть тесты на карме, которые в кармаконфиге инклудят конфиг вебпака. Можно это завести тут и как вообще в parcel дела с тестами обстоят?
xxxTy3uKxxx Автор
В официальной документации на этот счет ничего нет, поэтому скорее всего по старинке, ручным запуском команды. Но можно копнуть в сторону запуска Parcel через его экземпляр, как показано в этом примере внизу
kahi4
Да проблема не в том, как запустить тест через Parcel, а как к карме подцепить конфиг парселя, чтобы файлы корректно парсились, например, импорт svg.
xxxTy3uKxxx Автор
Думаю можно попробовать через инстанс бандлера провернуть
Надо проверить в бою
ZoNT
Я уже попробовал: по-умолчанию бандл собирается в папку dist. В итоговом html (который тоже лежит в папке dist) прописаны пути вида \dist\index.js. То есть нельзя просто собрать билд и выложить его из папки dist на сервер.
Как это вообще можно настроить в parcel — непонятно: вроде есть ключ --public-url, но он работает некорректно.
xxxTy3uKxxx Автор
Здесь посмотрите :)
ZoNT
Как будто я не прочёл всю доку перед использованием…
Пришлось форкнуть и внести изменения под свой проект.
xxxTy3uKxxx Автор
Я не знаю, зачем и что Вы форкали, потому что команда
генерирует такой вывод:
ZoNT
А теперь с той же командой запустите девелоп-сервер, положите в папку dist любой json и попробуйте загрузить его XHR-ом.
ZoNT
В общем вариант такой: либо нормально работает сборка и не работает dev, либо работает dev, но корень сервера определяется неправильно (не относительно папки dist)
superconductor
Так в 2017 для настройки всего этого специальный человек нужен — frontend build engineer.
А фронтендер — пишет компоненты на реакте.
Но ничего не верстает, для этого тоже отдельный человек.
Tihon_V
Т. е. Parcel позволяет использовать любые типы файлов в качестве assets и при этом не требует отдельной конфигурации для нового типа (только запуск в директории с исходниками и index.html)?
На мой взгляд теряется смысл различных связках boilerplate + webpack…
xxxTy3uKxxx Автор
Для типов, которые он не знает надо писать интерфейс для преобразования. А те, что знает — да, из коробки все без конфигов. Это покрывает многие мелкие проекты и задачи на 100%, как мне кажется
RubaXa
Всё правильно vlreshet говорит, вечные конфиги, rc-шки, соглашения и другие тайные занания. Почему никто не задумывается о
another-awesome-bundler init, который бы сам задетектилjsx,ts,less/sass/postcssи сконфигурил бы как надо? Хочешь продвинутой конфигурации, не вопросanother-awesome-bundler eject,create-xxxx-appведь создали, тут-то что мешает?xxxTy3uKxxx Автор
Я думаю дело в том, что комплексные и сложные проекты проще поддерживать, имея свой конфиг. Его можно вертеть и так, и эдак, кидать лоадеры и плагины из гитхаба (форки с доработками, например) и так далее по списку. Посмотрите репозитории angular-cli, react-create-app и их аналоги — все просят дать возможность расширять коробочные конфиги и так далее
Vampireos
эм… как так та?) Ведь всё установилось же
или ему очень нужна эта штука info fsevents@1.1.3: The platform «linux» is incompatible with this module.
xxxTy3uKxxx Автор
Судя по логу ярна — все в порядке. У Вас корректно выставлена переменная PATH?
Tihon_V
Нужен вывод
yarn config listиexport | grep " PATH=".Vampireos
xxxTy3uKxxx Автор
Ну собственно не видно у Вас в PATH пути до глобальных модулей, установленных через yarn
vintage
Ставить что-то глобально — дурной тон.
pletinsky
А через gulp его можно легко запустить?
xxxTy3uKxxx Автор
Внедрить в цепочку пайпов нельзя, но можно просто подклбчить как модуль и вызвать на нужный файл
aamonster
Простите, я с наивным вопросом: а почему инструменты для работы с JS тоже пишут на JS? Ведь это тянет за собой кучу проблем, которые приходится как-то решать ("использует worker process для многопоточной сборки" — весьма жирный намёк).
Неужели только желание оставаться в рамках одного языка?
Я понимаю ограничения в браузере — на юзерском компе что-то другое не вдруг выполнишь. Понимаю на сервере (хотя там другие скриптовые языки тоже используются). Но почему инструменты разработки делаются на том же языке?
P.S. В принципе, эта картина характерна не только для JS, но для него особенно заметна.
vlreshet
Возможно потому что так банально проще. Пример — какой-то модуль возвращает набор своих методов/классов, и js, естественно, спокойно этим манипулирует. В случае использования другого языка возникнет проблема понимания и разбора js, для взаимодействия с ним. Лишний труд.
justboris
Намек не очень понятный. Что именно здесь не так?
aamonster
Никакого "не так" здесь нет. Напротив, очень правильное решение.
Но многопоточность — не конёк JS (и это, в общем-то, нормально для его ниши и понятно в условиях ограничений, накладываемых браузером). В других языках она поудобнее, имеет больше возможностей, не имеет таких пенальти по быстродействию (обычно ценой меньшей безопасности — что приемлемо в данном случае).
justboris
Вот это очень спорное утверждение. Не вижу каких-то киллер-фишек, ради которых нужно тащить другой язык.
Зато есть анти-пример. По историческим причинам, node-gyp, использующийся для сборки нативных модулей, зависит от python, что причиняет немало трудностей при запуске в контейнерах и других минималистичных окружениях.
Гораздо удобнее работать, когда все написано на едином языке и ничего лишнего ставить не надо, кроме движка для этого языка.
aamonster
Текстовый редактор у вас написан на JS? Оконный менеджер? Операционная система?
Ну, вы поняли: когда речь идёт не о части вашего кода, а об инструменте для работы с этим кодом — удобнее уже собранный бинарник, и язык, на котором написаны его исходники, неважен.
justboris
К системе сборки приходится чаще писать плагины и обертки, чем к оконному менеджеру.
Поэтому исходники на знакомом языке и дружелюбное API на JS лишними не будут.
ZoNT
Текстовый редактор у меня написан на js: github.com/Microsoft/vscode
Tsimur_S
хочется просто набрать npm i и что бы все заработало а не возится с поиском бинарника. node-sass который использует бинарный libsass не всегда выкачивает готовый бинарник под платформу а начинает собираться на компе пользователя и тут начинается — скачай python, скачай visual studio и тд тп.
denisromanenko
Brunch.io гораздо проще и удобнее.
xxxTy3uKxxx Автор
Проще чем так же поставить пакет и запустить?
jesprider
В целом для простых проектов я думаю, что парсель — долгожданный продукт. Я правда ещё не пробовал, но если бы я захотел сейчас переходить на парсель с вебпака, то сразу возникает несколько вопросов:
1. Работаю с vue компонентами, парсель пока не поддерживает. Впрочем должно быть скоро имплементировано (https://github.com/parcel-bundler/parcel/issues/5). Но вопрос больше глобальный, как работать с фреймворком «х», если он требует дополнительного парсинга? И если начать поддерживать все фреймворки, то останется ли он таким быстрым? Или же нужно будет опять-таки конфигурировать?
2. Я не увидел из доументации, что там с хэшами для js и css файлов? Добавляет ли он их автоматически. Зачастую бывает необходимо выгрузить хэши в json, чтобы потом бэкенд мог из использовать.
3. Можно ли использовать алиасы и дополнительные плюшки, как то `webpack.DefinePlugin`.
4. Уверен, что для определённых юзкейсов размер сборки будет не оптимальным. Как дебажить и оптимизировать (a-la `webpack-bundle-analyzer`)?
xxxTy3uKxxx Автор
1) JS он отдает бабелу, а там через плагины можно обвязку сделать
2) Автоматически создает хэши и кладет файл sha.json со всеми хэшами
3) Можно использовать алиасы в бабеле, опять же
4) Пока такого нет, но думаю сделают :)
jesprider
Спасибо за ответ. Но не слишком ли много они ставят на бабел? По большому счёту уже сейчас можно начинать отправлять es6 модули. Тогда некоторые вопросы всё ещё актуальны.
На самом деле я не пытаюсь разразить жаркую дискуссию, и даже тот факт, что моя компания инвестирует в вебпак тут не при чём :) Просто мыслю вслух могу ли я в своём проекте перейти на парсель. Ответ: пока нет. Слишком много надо будет кастомного допиливать пока. Обязательно буду следить за развитием проекта.
xxxTy3uKxxx Автор
Я предполагаю, что решение сделать основную ставку на бабел (или постцсс) — это отличный способ избавится от своих собственных конфигов. По поводу вебпака — он его не заменит, только на простых проектах. Да и у него нет такой цели :)
jesprider
Согласен. Хотя такое чувство, что вебпак воспринял появление парселя близко к сердцу: twitter.com/TheLarkInn/status/941568697272958976.