{ block : 'libA/chart' } // bem-xjst modules.define('libA/chart') // ym :block(libA/chart) // post.css

{ block : 'libH/chart' } // bem-xjst modules.define('libH/chart') // ym :block(libH/chart) // post.css

или так

{ block : 'libA.chart' } // bem-xjst modules.define('libA.chart') // ym :block(libA.chart) // post.css

{ block : 'libH.chart' } // bem-xjst modules.define('libH.chart') // ym :block(libH.chart) // post.css

Кажется, что достаточно исключить «лишние» блоки из массива https://github.com/enb/enb-bem-techs/blob/master/techs/files.js (если используется enb):

  config.nodes( 'bundles/*', ( nodeConfig ) => {
    nodeConfig.addTechs([
      [techs.bem.levels, { levels: levels }],
      [techs.fileProvider, { target: '?.bemdecl.js' }],
      [techs.bem.deps, { target: '.?.deps.js' } ],
      [techs.bem.files, { depsFile: '.?.deps.js' } ], // ← вот тут
    ]);
  });

Зачастую библиотеки используют под капотом другие библиотеки в качестве зависимостей + есть еще вопрос версионирования. Поэтому мы остановились на том, чтобы самые частоиспользуемые блоки называть коротко и удобно.

@Realetive ну а что, если они не лишние? )

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

Кажется, что достаточно исключить «лишние» блоки из массива

Тогда уж в результирующем таргете files, и это будет работать только для enb. Опять же, если добить историю про нейминг на файловой системе типа lib1/button/button@desktop.js то можно было бы фильтровать по маскам внутри уровней прямо в передавая опцию в walk. p.s. Предвкушая вопрос почему сейчас нельзя — сейчас обход прохардкожен в walk и кастомизировать его сложновато.

либо публиковать отдельные библиотеки по каждому набору блоков.

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

Подвяжу к обсуждениям ответ @vithar

не однократно поднимался вопрос про возможноть при подключении библиотке указывать префикс, с которым будут использоваться блоки этой библиотеки, типа { lib: 'bem-components', prefix: 'bem' } и потом использовать bem-button вместо button. В частности, написание стилей через :block(…) делает это более возможным. Но полностью это реализовать нетривиальная задача, с одной стороны, и не приоритетная — с другой.

Неймспейсы для либ сами по себе выглядят как усложнение

согласен

Зачем изобретать велосипед, можно использовать готовые инструменты и экосистему npmjs, они уже добавили неймспейсы. Чтобы не плодить репозитории (как это делают тут http://atlaskit.atlassian.com/packages), есть инструмент https://www.npmjs.com/package/lerna используется https://github.com/bem/bem-sdk, но это не про интерфейс, но есть и про него https://github.com/primer/primer и https://github.com/fyndiq/fyndiq-ui, и наверное есть еще.

Для совместимости с текущими инструментами, надо будет только прокачать технологию deps.js, научить ее читать package.json.

Поправка atlaskit тоже используют монорепозиторий https://bitbucket.org/atlassian/atlaskit-mk-2/src/master/ и видимо обходятся без lerna. Дока у них крутая, сбила с толку.

@ilyar проблема в том, что может быть 2 блока calendar (с разной реализацией) в разных либах и они не должны ломать друг друга (в том числе через css)

Кроме костылей (в виде префиксов) или Центрального Реестра Блоков :) пока не понятно как добиться этого.

@belozer не понятна проблема, которую ты описываешь. Вот то о чем я говорю:

{
 "name": "project"
 "dependencies": {
    "@belozer/bem-calendar": "1.0"
  }
}

@ilyar

// libA/@common/button.bemhtml.js
block('button').content()((node, ctx) => ({ elem : 'text', content : ctx.text ))

// libA/@common/button.styl
.button
    display: flex

// libB/@common/button.bemhtml.js
block('button').content()((node, ctx) => ctx.text)

// libB/@common/button.styl
.button
    display: inline-block

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

Думаю чтобы попытаться решить появления похожих блоков (потенциально сдающих конфликты), самый простой путь Центральный Реестр Блоков, именно так решали эту задачу в развитии jQuery плагинов, есть гайд и место размещения с начало был bower а потом перешли на npm. И внезапно, для БЭМ-библиотек он тоже есть https://github.com/bem-contrib ему только не хватает крутой морды с гадом и рейтингом. И это правильный путь конкуренции и сотрудничества. Этот путь не возможен без поддержки, хотя бы до момента зарождения самоорганизации. Полагаю именно эту задачу решает лего внутри яндекса.

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

@belozer Это реальная проблема или фантазия?

Поправка atlaskit тоже используют монорепозиторий bitbucket.org/atlassian/atlaskit-mk-2/src/master и видимо обходятся без lerna. Дока у них крутая, сбила с толку.

У них bolt, аналог lerna.

Про депсы из package.json мы уже местами начинаем думать локально и подбиваем клинья, преобразуя текущее Лего к монорепо, но пререквизитом является поддержка кастомных уровней в walk и преобразование схемы на fs от {layer}.blocks/{entity}.{tech} к {entity}@{layer}.{tech}.

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

Но если даже каждый блок со всеми его элементами будет обладать общими зависимостями, то пока не решена проблема с честной модульностью блоков — и тогда вопрос с «неймспейсами» встаёт более остро, ведь будет возможность даже не желая того привезти один компонент двух разных версий в браузер, или не встаёт, если мы всё равно не хотим лишний код в браузере, и тогда можно будет для UI модулей просто не использовать NPM (?).

В общем, копать и копать).

p.s. А еще можно взять реакт с css-in-js ;-) и мучаться с другими проблемами, еще менее приятными).

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

это должен решить пакетный менеджер и семвер, если он не может решить, то

и тогда вопрос с «неймспейсами» встаёт более остро

в реальности это будет означать что одна либа не очень активно обновляет свои зависимости и уверен не правильно хотеть решить это «неймспейсами»

@component-namespace mine {

    @component SearchForm {
        padding: 0;
        margin: 0;

        @modifier advanced {
            padding: 1rem;
        }

        @descendent textField {
            border: 1px solid #ccc;

            @when invalid {
                border: 1px solid red;
            }
        }

    }
}

Вот что есть про namespace Using PostCSS with BEM and SUIT Methodologies by @kezzbracey