Pull to refresh

Comments 27

А есть подсветка синтаксиса? Хоть для какого-нибудь редактора…
Шикарно, спасибо. Еще бы плагинчик для browserify, но это я сам, может быть, попробую…
Забыл про Browserify, каюсь, сделаю. Просто я давно сполз на WebPack и забыл о Browserify :)
Честно говоря, лучше просто перейти на вебпак) Хотя понимаю, что это не всегда бывает возможным.
При всем уважении, я попробовал разок и мне не понравилось.
как может не понравится то, что хорошо :) Может вы не те доки читали? Он достаточно прост, без соплей как в gulp (хотя это иногда дает некоторые удобства в представлении того, что происходит)
Последний раз, когда я проверял, с доками было грустно. Хороших туториалов тоже не попадалось. И hello world на реакте весом в метр и 20k LOC как-то не вдохновляет.

Ну, он не для Hello World'ов, а для сборки средних и крупных проектов со сложными зависимостями.


А вообще — достаточно почитать "motivation". чтобы понять, зачем он и для чего.
http://webpack.github.io/docs/motivation.html

Не стоит вдохновляться теми, кто не осилил)

То есть я должен использовать два разных сборщика, один для сложных проектов, один для простых? В принципе, не проблема, конечно, и так где grunt, где gulp, где кучка npm-скриптов, но все-таки…

Да при чем здесь сборщик и реакт? Собирайте без реакта для маленьких проектов. Собирайте jsx без реакта хоть на своей либе. Собирайте tsx без реакта на своей либе. Собирайте css, html, js — как хотите и куда хотите. Собирайте статику, spa, да хоть расширения для броузеров. Зачем упираться только в реакт?

Gulp — это таск-раннер, webpack — сборщик. Таск-раннер выполняет задачи в указанной последовательности. Сборщику указываются входные точки, и он собирает выходной файл со всеми зависимостями. По сути, это можно сравнить с компиляцией в компилируемых языках, когда собирается итоговый экзешник. Вебпак хорош тем, что он может собрать один (или не один) итоговый файл из вообще всех зависимостей: картинок, стилей, шаблонов — чего угодно. Например, в моём проекте я использую БЭМ-подход. Каждый блок представлен папкой, в которой лежит его шаблон (на Snakeskin), класс (на ES2015) и стили (Stylus). Блоки могут наследоваться, также у них есть зависимости (другие блоки). Страницы — это тоже блоки, которые являются входными точками для Webpack. Вебпак собирает весь проект в несколько бандлов, компилируя шаблоны и стили, прогоняя JS через бабель, вынося общие для нескольких страниц блоки в отдельные .css и .js файлы.


Вот зачем нужен вебпак.

Но ведь то же самое я делал (и делаю) на browserify и, прости господи, grunt/gulp — прогоняя JS через babel, с jade и stylus. При этом я могу отдельно от остального собрать стили и перекомпилить шаблоны. Без оверхеда в почти мегабайт. Ну вроде бы бандловую арифметику browserify не умеет, но если у каждого бандла будет этот меговый довесок, то и не надо.

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

Расскажите, лол, как с помощью чистого галпа собрать бандл из index-файла с кучей зависимостей. Или как с помощью чистого browserify собрать клиентскую часть так, чтобы стили (которые ещё надо пропустить через stylus и autoprefixer), сохранились как отдельные бандлы (скажем, один common.css и ещё отдельный для каждой страницы), а шаблоны для генерации HTML-кода страниц (которые потом использует нода) чтобы вообще лежали в отдельной папке. Входных точек (страниц) — пять, а блоков — несколько десятков. И чтобы в js-файле для страницы появился класс блока, а в css-файле — его стили, мне достаточно просто указать блок в списке зависимостей страницы.


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


Вебпак — сложная штука, но стоит потратить на его изучение несколько дней, оно окупится) Разница между ним и browserify — примерно как между WebStorm и Notepad++. Код можно писать и там, и там, и даже, вроде как, разница по функциям в мелочах, в общем-то… Но на самом деле, она огромная)

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

Да не, он же писал — хелловорд на реакт. Вебпак подтянул реакт в проект, да и реакт-дом тоже наверно. Ну и без минификатора, само собой, без дедупликации опять же, а там смотреть надо, какие пакеты помимо реакта подключались.

А, да, возможно, кстати. Вебпак вообще любит подтянуть всё, что только можно — например, все локали для moment. Не скажу, что это плохо, но иногда такое поведение приходится ограничивать.

думаю будет удобнее в репозитории хранить исходники плагина, а джарку можно загружать во вкладке releases, так в ваш плагин смогут контрибьютить
извиняюсь, если скопитанил :)

К огромнейшему сожалению, это не плагин. Это настройки для "Editor -> FIle Types" в WebStorm)

извиняюсь, упустил в ридми File->Import Settings->Choose «snakeskin.jar»

но в релизы добавить не помешало бы, чтобы в один клик скачать, не клонируя репозиторий (View Raw не считаю за правильный метод)
справедливости ради в джарке удобочитаемые xml исходники конфигов которые можно было бы и версионировать ;)
Дайте ссылку на первые версии вашего шаблонизатора, который был на регулярках
На GitHub в истории можно посмотреть легко.
если я не ошибаюсь, если судить по тегам, там версия начинается с 2.3, а хотелось бы посмотреть именно первые версии
Sign up to leave a comment.

Articles