@kompolom Давно думаем и обязательно придем к этому. Есть несколько задач, которые хочется решить:

1. Текущие конфиги сборки библиотек слишком верборзные и их поддержка отнимает приличное количество времени. Необходимо обобщить их в лаконичный декларативный формат.
2. Инструменты сборки постоянно развиваются и предоставляют все больше данных для генерации сайта библиотеки. При этом на стороне сайта приходится поддерживать все легаси-форматы. Хочется уйти от подхода, когда библиотека инкапсулирует знание о том, как по ней собрать сайт к инструменту, который бы вызывался сбоку. Это бы позволило поддерживать только один формат на стороне сайта.

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

А пока у нас есть страничка «Проекты на БЭМ», куда мы приглашаем присылать пулл-реквесты с описанием библиотек из комьюнити.

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

А чо так заумно, я вот не понял!

А пока у нас есть страничка «Проекты на БЭМ», куда мы приглашаем присылать пулл-реквесты с описанием библиотек из комьюнити.

было бы круто bower search bem и на тебе список

А чо так заумно, я вот не понял!

Не верю, конечно ;) Но смысл в том, что сейчас знание о том, как собирать документацию (на разных языках с подсветкой синтаксиса), примеры (заинлайненные в документации прямо в md и отдельные бандлы), JSDoc и все остальные знания, которые нужны сайту, хранит в себе библиотека. Эти знания версионируются вместе с библиотекой. И когда выходит новая версия хайлайтера, генератора JSDoc-а или сборщик начинает предоставлять новые полезные данные, все это сейчас нельзя использовать для уже выпущенной версии, на которой поставлен тег. А на строне сайта приходится поддерживать все форматы за всю историю всех инструментов, вызываемых для сборки библиотеки (bem-pr, bem-sets, enb-bem-docs и куча их версий). А кроме того, в самих конфигах выпущенных библиотек бывают ошибки. Для них тоже приходится делать фоллбеки или манки-патчить результаты сборки. Поэтому добавление каждой новой библиотеки сейчас автоматически означает не просто одноразовую задачу, а регулярную поддержку. Как это дело исправить, мы, кажется, придумали. Осталось всего ничего — взять и запрограммировать ;)

bower search bem плюс-минус и так работает ;)

Осталось только всем в имени или описании библиотеки использовать bem :)

@verybigman ну не только. есть еще проблемка с именованием и разделителями.

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

К примеру я подключаю bem-core и хочу использовать несколько блоков вроде link и image из нее, а остальные блоки вроде button, input и т.д используются из проектных блоков. Приходится изучать какие имена блоков уже имеются в bem-core и если есть совпадение, то приходится придумывать новое название, ну к примеру для того же button, который, свой в доску, кастомный на проекте.

Что думаете по этому поводу?

А вы готовы в css/js/bemhtml, вместо .link/'link' писать .%blockname%/'%blockname%, вместо linkpseudo писать `%elemname%%pseudo%`, или еще как-то абстрагироваться ;-) Ибо иначе переименовывать, да еще и в динамике, и с гарантией — сложно.

Или у вас есть другие идеи?

@zxqfox, как я понял, @4ok говорит о том, что готов писать вместо .link / 'link' что-то вроде .bem-components--link / bem-components--link

По-моему, смысл в максимальном переиспользовании и тут отсутствие неймспейса как бы намекает: парень, это это уже сделали, зачем тебе велик?:) Я не верю, что у вас такая кнопка, которую не имеет смысла базировать на кнопке из компонент. Или инпут, совсем совсем не такой.

@apsavin Я понимаю, что он на проекте готов это писать. Но чтобы это можно было делать для библиотеки, и при подключении префиксировать неймспейсом, или еще как-то выделять — нужно, чтобы работало переименование прямо в библиотеке (а лучше, сразу везде), иначе заменить link в блоке link на alien--link безопасно невозможно. Оно будет работать, но не всегда. Да и надо понимать, что в этом случае мы когда переопределяем в других библиотеках блок link мы должны будем указывать, какой именно линк мы переопределяем, из какой именно библиотеки — это всё задачи, которые кажутся не самыми важными, но без которых неймспейсы полноценно сделать невозможно. А если нельзя полноценно — то и руки опускаются ;)

Было бы хорошо (и это сделать просто) иметь возможность просто не подключать те блоки, которые не нужны (т.е. фильтровать блоки при указании уровней). Это не требует всего этого зоопарка и с этим можно пожить, если сильно мешает, как в случае @4ok.

cc @tadatuta Могем такое запилить? Хотя, наверное, @andrewblond будет правильнее позвать.

@verybigman Тут тоже согласен, но «кнопки» бывают разные. ;-)

Мне показалось, что @4ok имел в виду использование подобных неймспейсов прямо в библиотеке, без необходимости что-то переименовывать. Просто называть блоки специфично для библиотеки.

@apsavin В таком случае 80% пользователей будут против, потому что такие длинные имена это ад и израиль ;-). Да и все равно это не решает проблемы расширения блоков одной библиотеки блоками другой библиотекой. Если имена специально пересекаются — это снова будет путать людей.

@zxqfox

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

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

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

@zxqfox Исходная проблема была в отсутствии информации, какие кастомные блоки есть в опенсорсе, и где они лежат. А чтобы блоки не мешались, не нужно ложить лишнее в библиотеку... Как раз об этом я и писал выше.

Что касается коллизий в именах, с этим можно жить. И как мне кажется, чем больше информации о существующих блоках, тем меньше коллизий.

@kompolom А, ты про это. Ну да, я бы тоже в эту сторону копал. Тут вопрос в том, где и как хранить реестр этих самых блоков, и как рулить совместимостью библиотек. Вопрос уже года 2 витает, но на фоне всех остальных задач как-то никто не рискует это делать, все слишком разношерстно.

И согласен, что коллизий было бы меньше, зная мы названия всех возможных блоков. Сразу хочу неверующим ответить, что мол у одних input это бабка, а у других — дедка: input он если и бабка, и дедка, и черт лысый, то не надо перегружать его базовый функционал, и все будет нормально ;-) И коллизии не будут мешать. Но выбирать только нужные блоки из библиотеки — было бы ок норм вообще.

Для каждой библиотеки необходим немспейс, без него никак

Есть еще идея про bem mv (прототип https://github.com/tadatuta/bem-mv#add-prefixes-to-all-blocks-on-all-levels-in-bem-components-library — см. последний пример из доки).