Если вам нужны только базовые шаблоны bemthml, bemtree, то можно вообще отказаться от подключения bem-core, скопировав i-bem.bemhtml, i-bem.bemtree к себе на проект.

плюс блок page

@tadatuta @Guria Это я понял, но удаляя i-bem.js из папки bem-core , вызывает ошибку в отладчике. Можно какой-нибудь маленький примерчик глянуть?

• удалить bem-core и bem-components из bower.json и папки lib/
• удалить соответствующие строки в конфиге сборщика (.enb/make.js)
• положить в common.blocks:

i-bem/
  i-bem.bemhtml
  i-bem.bemtree
page/
  page.bemhtml

• не забывать у каждого блока с шаблонами указывать mustDeps: 'i-bem'

@Rahnar а можете подробнее описать задачу? откуда взялось такое желание?

@veged Я на днях с этим тоже сталкивался, у меня кастомная сборка i-bem (из bem-bl старая) на проекте, и туда нет возможности загружать еще один i-bem из bem-core. В итоге пришлось выносить на отдельный уровень чистый bemhtml. ;-( При чем, на остальные 2 площадки я собирал с уровнем из bem-core. Т.е. это исключение, скорее, но очень проблемное

@zxqfox я не очень понимаю, зачем нужно скрещивать в одном рантами bem-bl и bem-core — это обе библиотеки про одно и то же и они будут конфликтовать, работоспособность таких мутантов никак не поддерживается

@veged Задача в использовании Ангулара. Потому что, i-bem.js конфликтует с angular. И человеку было тяжело описывать модульную архитектуру ангулара в мерках БЭМ. Мое мнение , если использовать БЭМ, то пользоваться исключительно его внутренними технологиями. Но на проекте идет ангулар.

@Rahnar но я не понимаю, как вы хотите использовать блоки без js (который весь использует i-bem.js внутри) — вы можете весь js реализовать сами средствами ангуляра, но тогда достаточно вообще не подключать никакого js от bem-components

@veged именно так и поступил , неделю назад :))

@veged В рантайме не надо ничего скрещивать. Проблема была в том, что bemhtml тянет за собой i-bem.js, bemhtml из bem-core вполне годный и для i-bem из bem-bl (за мелкими исключениями). Но т.к. i-bem нам собирать не надо (он у нас собран ручками и не трогается), а некоторая часть тянет bem-core — то тянуть bem-bl ради bemhtml как-то странно. В рантайме, естественно, страницы полностью собранные в bem-core работают со свежим i-bem, а старые — по большей части рисуются смарти и используют старый bem-bl. Проблема же возникла когда нам нужно было собрать небольшой блочок в бандл вместе со стилями и скриптами и раскидать на несколько сайтов (на котором в рантайме уже есть i-bem из bem-bl), и .js мы реализовали так, чтобы не конфликтовал, но мы не захотели переписывать еще и bemhtml шаблон на смарти и вот проблема и возникла. Я понятно объясняю, да? ;-)

Т.е. проблема не частая, но очень неприятная, и мешает переходу Ы→core. Как и отсутствие в i-bem из Ы опциональной модульной сборки — ничто же не мешает опционально дать возможность оборачивать свежий код (и переводить по возможности старый) в модули. Но это возможно только при некоторой кастомизации, которая, кмк, нужна каждому, кто сталкивается с такими переходами.

@veged Расскажу в тему свою историю. Для нас jQuery является очень медленным и глючным. По сему отказываемся от него полностью. Однако i-bem на нем женат. Взяв библиотеку bem-core, захотелось не писать своих page, link и прочих блоков, уже, ведь, есть!

Но как не крутил не вертел, пришлось копипастить то, что было в bem-core на свой слой переопределения и выпиливать от-туда i-bem.

Очень хочется иметь простой базовый набор блоков, который можно использовать as is, а всякие i-bem уже навешивать отдельно.

А пока всё копипастим да переписываем. Что как-то не по православному.

@pavelpower так можно же было отказаться от .js технологии, использовать все, кроме .js, и js писать самому (назвать только иначе, а потом переименовать через тот же fileCopy/fileMerge).

@zxqfox ага, но это уже танцы с бубном. Проще оказалось скопипастить

@Rahnar i-bem и angular не конфликтуют если их правильно приготовить