bem version - не библотека, а подкоманда к bem-tools 1.0.0, аналог npm version. Стабильна, активной разработки не предвидится - утилита довольно маленькая и узконаправленная.

project-stub на yeoman видится перспективным - начинал его делать, но забросил, также готов присоединиться.

bem-tools [любой версии] в продакшене» не имеет смысла, т.к. в продакшен попадает уже готовый код. если текущая альфа bem-tools@1.0.0 успешно собирает проект, то можно пользоваться.

другими словами ничто не останавливает реализовывать динамический БЭМ-сайт на Node.js, я правильно понял?

общий вопрос bem stack stable – стабильный набор инструментов, которые можно использовать для новых проектов.

считаю это наиболее актуальный вопрос, создал документ project-stub on bem stack stable цель которого на основе project-stub понять понять что входит в стек, что устарело, что является базовым, а что опциональным.

другими словами ничто не останавливает реализовывать динамический БЭМ-сайт на Node.js

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

запросил доступ к документу

Будет полезно иметь план поддержки компонентов, например:

Легенда:

• p — будущая версия
• b — открытое тестирование
• c — текущая версия
• s — поддерживается
• o — не поддерживается
• f — заморожен

Это позволит контрибютерам планировать миграции текущих проектов и актуально конфигурировать новые.

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

Меня не оставляет в покое одна мелочь, если к моменту деплоя bem-tools больше вообще не нужен, то место этого пакета в devDependencies:

  "dependencies": {
-    "bem": "0.7.4",
    "bem-environ": "1.3.1"
  },
  "devDependencies": {
+    "bem": "0.7.4"
  },

Это так?

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

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

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

Сделал версию project-stub c vagrant+bem-tools-1.0.0 + bem-core https://github.com/alexbaumgertner/project-stub

Приглашаю потестировать :)

замечательно и у меня антологичное предложение https://github.com/ilyar/chef-bem

соответственно нет смысла говорить о поддержке версии с тремя чиселками...

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

project-stub на yeoman видится перспективным - начинал его делать, но забросил, также готов присоединиться.

@SevInf, заброшенный проект есть в паблике?

У меня есть вопросы текущим настройкам project-stub@bem-core логу bem make им место в этом обсуждении или правильнее спросить в клубе?

Правильнее в клубе

08.01.2014, 17:23, "Ilya Rogov" notifications@github.com:

У меня есть вопросы текущим настройкам project-stub@bem-core логу bem make им место в этом обсуждении или правильнее спросить в клубе?

— Reply to this email directly or view it on GitHub.

##

Отправлено из мобильной Яндекс.Почты: http://m.ya.ru/ymail

@ilyar пока нет, постараюсь на днях привести в более-менее приличный вид и выложить