Pull to refresh

Comments 68

UFO just landed and posted this here

Давайте по порядку.


Откуда вы их взяли?

Из официальной документации и, самое главное, из документации Babel и PostCSS. Знаете как использовать — используйте. Не знаете — почитайте, попробуйте. Никто же не заставляет :)


Такое ощущение что в мире js ничего не имеет конфигов по умолчанию, нельзя просто сделать install и запустить всё на стандартных настройках

Можно, больше Вам скажу — на главной странице пример, который не требует ни одного конфига для Babel или PostCSS. Если они Вам не нужны — не пишите. Тут сыграло роль то, что статья носит чисто информативный характер, и если в нее вставить еще более простой пример, то Вы никак не увидите его главный плюс, заключающийся в отсутствии необходимости писать даже маленький сферический webpack.config.js


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

Так в статье нет ни одного конфига для самого Parcel :)

UFO just landed and posted this here

Хотите LESS — импортируйте .less файл и он добавится в бандл. Хотите VueJS — импортируйте в бандл. Суть в том, что вы скармливаете в Parcel некую точку входа. Он начинает анализировать ее вглубь, строя дерево зависимостей. Поэтому, если в ваш импорт попадает тот или иной файл — он оказывается в итоговом бандле.
Возможно, я слишком вскользь упомянул это в данном абзаце:


У нас есть сущность — Asset. Ассет — это любой файл. Механика работы такова: реализуется интерфейс, который предоставляет логику для превращения файла в AST, разрешения всех зависимостей, применения нужных трансформаций и генерирования итогового кода.

CSS не нужно тянуть через JS, Вы можете импортировать его через другой CSS файл, подключить в HTML или, опять же, в JS. Пример использовал так называемые CSS Modules для наглядной демонстрации того, что в вебпаке потребовало бы конфигурации.


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


Подводя итог — попробуйте создать обычный HTML, подключить в нем SCSS в теге <style> и свой JS-файл в теге <script>, в котором докиньте Vue и запустите команду parcel index.html. И все, никаких CSSinJS и прочего.

UFO just landed and posted this here

Не за что, рад что стало немного яснее :) Надо вынести в статью информацию о том, как происходит разрешение зависимостей.

UFO just landed and posted this here

Есть плагин
Сейчас сам пишу плагин для Pug. Кода немного, раздумываю, стоит ли написать ради этого статью с объяснением работы.

Здравствуйте. Как ваш плагин для Pug поживает? Наткнулся на Parcel, сразу возник вопрос, смогу ли я использовать Pug вместе с ним.

Добрый день. Есть некоторые недоработки, но весь базовый необходимый функционал работает.

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

Согласен, но тут конечно вся прелесть в том, что инструмент из разряда «поставил, нажал, заработало». Примерно так же многий софт под macOS позиционируется :) Данный принцип здорово подходит, когда тебе не нужно искать шаблон для yeoman (или писать свой), а просто надо в полпинка запустить окружение и делать разные клевые штуки. Возможности вебпака больше, это бесспорный факт.

Данный принцип здорово подходит, когда тебе не нужно искать шаблон для yeoman (или писать свой), а просто надо в полпинка запустить окружение и делать разные клевые штуки.

Да, тут не поспоришь. Хоть я и в состоянии написать сколь угодно громоздкий конфиг вебпака, всегда когда нужно быстро на коленках собрать и проверить mvp один и тот же геморрой с boilerplate, которые частично не работают/слишком переусложнены/устарели и прочее.


Глубоко не копал, но все же — вот у меня есть тесты на карме, которые в кармаконфиге инклудят конфиг вебпака. Можно это завести тут и как вообще в parcel дела с тестами обстоят?

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

Да проблема не в том, как запустить тест через Parcel, а как к карме подцепить конфиг парселя, чтобы файлы корректно парсились, например, импорт svg.

Думаю можно попробовать через инстанс бандлера провернуть


const Bundler = require('parcel-bundler');
let bundler = new Bundler('src/App.js');

Надо проверить в бою

Я уже попробовал: по-умолчанию бандл собирается в папку dist. В итоговом html (который тоже лежит в папке dist) прописаны пути вида \dist\index.js. То есть нельзя просто собрать билд и выложить его из папки dist на сервер.
Как это вообще можно настроить в 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>
А теперь с той же командой запустите девелоп-сервер, положите в папку dist любой json и попробуйте загрузить его XHR-ом.
В общем вариант такой: либо нормально работает сборка и не работает dev, либо работает dev, но корень сервера определяется неправильно (не относительно папки dist)
Вопрос, а если у меня в проекте 2 точки входа в виде html файлов (вызываются при разных условиях), можно ли это собрать в общий bundle?

Так в 2017 для настройки всего этого специальный человек нужен — frontend build engineer.
А фронтендер — пишет компоненты на реакте.
Но ничего не верстает, для этого тоже отдельный человек.

А как вы сделали автопрефиксер на мавене?
Т. е. Parcel позволяет использовать любые типы файлов в качестве assets и при этом не требует отдельной конфигурации для нового типа (только запуск в директории с исходниками и index.html)?

На мой взгляд теряется смысл различных связках boilerplate + webpack…

Для типов, которые он не знает надо писать интерфейс для преобразования. А те, что знает — да, из коробки все без конфигов. Это покрывает многие мелкие проекты и задачи на 100%, как мне кажется

Всё правильно 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

Ну собственно не видно у Вас в PATH пути до глобальных модулей, установленных через yarn

yarn add parcel-bundler
yarn parcel index.html

Ставить что-то глобально — дурной тон.

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

Простите, я с наивным вопросом: а почему инструменты для работы с JS тоже пишут на JS? Ведь это тянет за собой кучу проблем, которые приходится как-то решать ("использует worker process для многопоточной сборки" — весьма жирный намёк).
Неужели только желание оставаться в рамках одного языка?


Я понимаю ограничения в браузере — на юзерском компе что-то другое не вдруг выполнишь. Понимаю на сервере (хотя там другие скриптовые языки тоже используются). Но почему инструменты разработки делаются на том же языке?


P.S. В принципе, эта картина характерна не только для JS, но для него особенно заметна.

UFO just landed and posted this here
"использует worker process для многопоточной сборки" — весьма жирный намёк

Намек не очень понятный. Что именно здесь не так?

Никакого "не так" здесь нет. Напротив, очень правильное решение.
Но многопоточность — не конёк JS (и это, в общем-то, нормально для его ниши и понятно в условиях ограничений, накладываемых браузером). В других языках она поудобнее, имеет больше возможностей, не имеет таких пенальти по быстродействию (обычно ценой меньшей безопасности — что приемлемо в данном случае).

В других языках она поудобнее, имеет больше возможностей

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


Зато есть анти-пример. По историческим причинам, node-gyp, использующийся для сборки нативных модулей, зависит от python, что причиняет немало трудностей при запуске в контейнерах и других минималистичных окружениях.


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

Текстовый редактор у вас написан на JS? Оконный менеджер? Операционная система?
Ну, вы поняли: когда речь идёт не о части вашего кода, а об инструменте для работы с этим кодом — удобнее уже собранный бинарник, и язык, на котором написаны его исходники, неважен.

К системе сборки приходится чаще писать плагины и обертки, чем к оконному менеджеру.


Поэтому исходники на знакомом языке и дружелюбное API на JS лишними не будут.

хочется просто набрать npm i и что бы все заработало а не возится с поиском бинарника. node-sass который использует бинарный libsass не всегда выкачивает готовый бинарник под платформу а начинает собираться на компе пользователя и тут начинается — скачай python, скачай visual studio и тд тп.

Проще чем так же поставить пакет и запустить?

В целом для простых проектов я думаю, что парсель — долгожданный продукт. Я правда ещё не пробовал, но если бы я захотел сейчас переходить на парсель с вебпака, то сразу возникает несколько вопросов:

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) Пока такого нет, но думаю сделают :)

Спасибо за ответ. Но не слишком ли много они ставят на бабел? По большому счёту уже сейчас можно начинать отправлять es6 модули. Тогда некоторые вопросы всё ещё актуальны.

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

Я предполагаю, что решение сделать основную ставку на бабел (или постцсс) — это отличный способ избавится от своих собственных конфигов. По поводу вебпака — он его не заменит, только на простых проектах. Да и у него нет такой цели :)

Да уж, забавно. Глуповато, мне кажется. Никто не списывал вебпак со счетов, он по прежнему является очень мощным инструментом, и парсель его никак не заменит

Священные коровы индийских полей… ну почему? Почему в мире js каждые два года появляется новая «революционная» технология, которая живет ровно два года, а потом резво откидывает копыта?
grunt, gulp, webpack, rollup (наверняка, я что-то пропустил), и теперь вот parcel… ждем два года, и встречаем новый <убер-пупер-придумайте-название-сами> сборщик, который заткнет всё старое за пояс. И принесет дзен в мир фронтенда. Но не дольше, чем на два года.

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


Насильно вам их никто не навязывает, можно продолжать пользоваться старыми, если все устраивает

Да это замечательно. Просто не очень легко поспевать за всем этим.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Да и Google использует webpack в angular-cli

Да не вопрос, вот свежачёк microbundle (zero-configuration bundler for tiny modules), всего неделю назад вышел и уже 1.5K✰

Microbundle не в счет. Это просто обертка вокруг относительно известного Rollup.

В счёт, что там под копотом не важно, главное суть --> это очередной бандлер.

Ну, по такой логике и create-react-app, next.js и т.п. тоже очередные бандлеры, хотя все они надстройки над webpack.

Нет, они генераторы бойлерплейта.

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

UFO just landed and posted this here
Sign up to leave a comment.

Articles