Друзья, начинаем регистрацию на очередной BEMup — митап по БЭМ, который пройдет в Москве 24 мая в 19:00.

На эту встречу мы пригласили дизайнеров рассказать про создание дизайн-системы на основе http://whitepaper.tools.

Регистрируйтесь скорее, количество мест ограничено! https://events.yandex.ru/events/bemup/24-may-2019/

Пример:

<div class="block-name">
   <div class="block-name__item">
      <div class="block-name">
         <div class="block-name__item">
            etc.
         </div>
      </div>
   </div>
</div>

<div class="popup popup_A">
      <div class="popup__container">
        <div class="popup__header">
          <div>Знакомства</div>
          <div class="popup__close">x</div>
        </div>
        <div class="popup__content enabled-notification">
          <div class="enabled-notification__title">Включить уведомления</div>
          <div class="notification">
            <div>
              <div class="notification__title">Новое сообщение</div>
              <div class="notification__desc">Ирина: Привет! Встретимся сегодня у фонтана в парке</div>
            </div>
            <div class="notification__icon">
              <svg xmlns="http://www.w3.org/2000/svg"></svg>
            </div>
          </div>
          <div class="enabled-notification__text">
            Вы разрешаете нам отправлять уведомления о новых сообщениях, комментариях на ваши заметки и т.д.?
          </div>
        </div>
        <div class="popup__footer popup_A__footer">
          <button class="btn btn_color_grey popup_A__btn">Нет, спасибо</button>
          <div class="divider"></div>
          <button class="btn btn_color_blue popup_A__btn">Включить</button>
        </div>
      </div>
    </div>

Блок "popup" ре-используемый, может содержать различный контент. Блок "enabled-notification" уникальный и не будет ре-использоваться. Блок "notification" ре-используемый, может содержать различный контент, в рамках определённых элементов.

Для модификации кнопок (нужно было сделать ширину в 50%), используем микс с модификатором popup_A. В обычном состоянии у "popup" есть только одна кнопка.

.popup_A__footer{
  display: flex;
  justify-content: space-between;
}
.popup_A__btn{
  width: 50%;
}

Ещё есть вопрос по использованию "пустых" тегов-элементов (без классов), допустимо ли это?

<div class="notification">
            <div>
              <div class="notification__title">Новое сообщение</div>
              <div class="notification__desc">Ирина: Привет! Встретимся сегодня у фонтана в парке</div>
            </div>
            <div class="notification__icon">
              <svg xmlns="http://www.w3.org/2000/svg"></svg>
            </div>
          </div>

Допустим у меня есть блок .article:

<div class="article">
  <h1 class="article__heading"></h1>
  <img class="artilce__image">
  <p class="article__text"></p>
</div>

Я хочу видоизменить его внутри блока .frontpage, при этом сохранив привязку к .article. Для этого я использую микс только к .article:

.frontpage{
  &__article{
    .article{
      &__heading{}
      &__image{}
      &__text{}
    }
  }
}

Такой подход (в отличии от миксования к каждому изменному блоку) позволяет мне не засорять пространство имен (никаких .frontpage__article-heading), и вроде бы не ломает модульность.

Соответствует ли он методологии?

Привет. Есть вот такой футер:

который можно разделить на два больших элемента:

И получается такая структура:

footer
  footer__wrapper
    footer__item footer__item_columns
    footer__item footer__item_info

Это правильная структура и названия?

И еще внутри есть такие колонки:

И как лучше всего сделать колонки? Сделать их блоками или элемантами? Как тогда лучше обозвать их? Была идея navbar-column, но в колонке может не быть navbar(последняя колонка). Или сделать это элементами футера? Но тогда слишком много зависимости от футера будет и плюс хочется использовать класс wrapper для колонки примерно так:

noname-column
  noname-column__wrapper
    noname-column__header
    noname-column__content

        <div class="infg">
            <div class="infg__item">
                <div class="infg-icon">
                    <img src="/images/implant.svg" class="infg__icon" alt="">
                </div>
                <div class="infg__desc">
                    <div class="infg__title"></div>
                    <div class="infg__text"></div>
                </div>
            </div>
        </div>

Вопрос: правильно ли я сделал именование классов согласно БЭМ? Как будет правильно назвать класс 'infg-icon' который находиться в div`?

Блоки и темы оформления.

Уже давно пытаюсь избавиться от боли модификатора _theme у блоков. У нас 2 темы блока button - публичная и админка, около 2K строк стилей в сумме.

Имхо, блок должен быть максимально реиспользуемым и не тянуть ненужный код. Сейчас под тему запихиваются ВСЕ комбинации модификаторов блока, даже если они не нужны на странице. Это боль в поддержке.

Очень близки идеи http://whitepaper.tools/. В целом работаю тоже в этом направлении.

На данный момент пришёл к использованию 2-х видов переменных.

1. Глобальные/Контекстные (что реализовано в whitepaper)

Задаются через блок theme и модификаторы theme_color_* theme_size_* и т.д. Провайдят контекст переменных вниз по дереву.

.Theme_color_light {
  --color-bg: #f7f7f7;
  --coloron-bg: #222; 

  --color-primary: #222;
  --coloron-primary: #fff;

  --color-secondary: #777;
  --coloron-secondary: #ddd;

  --color-surface: #fff;
  --coloron-surface: #222;

  --color-error: #d00;
  --coloron-error: #fff;

  --color-success: #090;
  --coloron-success: #fff;
}

2. Локальные (Уровень блока)

Задаются с указанием префикса имени блока. Такой способ явно ограничивает пространство имён переменных, чтобы случайно не сломать что-то внутри дерева. И позволяет легко изменять их через модификаторы.

Если спроецировать на мир React, то контекстные переменные - это пропсы, локальные - стейт :)

.Button {
  --Button-bg: var(--color-bg);
  --Button-border: var(--color-secondary);
  --Button-color: var(--color-primary);
  --Button-shadow: var(--color-bg);
  --Button-fontSize: 1rem;

  background: var(--Button-bg);
  border: 1px solid var(--Button-bg);
  color: var(--Button-color);
  padding: 1em 2em;
  font-size: var(--Button-fontSize);
  transition: .3s;
  border-radius: 3px;
}

.Button:hover {
  background: var(--Button-color);
  color: var(--Button-bg);
  cursor: pointer;
  box-shadow: 0 10px 20px var(--Button-shadow);
}

.Button_disabled,
.Button_disabled:hover {
  background: #ddd;
  border-color: #ddd;
  color: #999;
  cursor: default;
  box-shadow: none;
}

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

3. Модификаторы

Дальше через модификаторы жонглируем уже локальными переменными блока.

.Button_color_action {
  --Button-bg: var(--color-action, #00a);
  --Button-color: var(--coloron-action, #fff);
}

.Button_color_error {
  --Button-bg: var(--color-error, #f00);
  --Button-color: var(--coloron-error, #fff);
}

.Button_color_success {
  --Button-bg: var(--color-success, #090);
  --Button-color: var(--coloron-success, #fff);
}

Данный подход позволяет избавиться от длинных селекторов в css.

Например если мы не хотим использовать локальные переменные, то нужно писать классы таким образом

.Button_color_success {
  background: var(--coloron-success, #fff);
  color: var(--color-success, #090);
}

.Button_color_success.Button:hover {
  background: var(--color-success, #090);
  color: var(--coloron-success, #fff);
}

И это только 2 состояние, а там ещё N состояний, включая вложенные элементы...

Локальные переменные, конечно не серебренная пуля и каскады писать придётся. Но как решение вполне может помочь добиться лаконичных селекторов.

4. Именование цветов

После долгих ресёрчей толком не нашёл способа лаконично и предсказуемо описывать переменные. Наиболее лаконичным стилем нашёл подход из Material Design https://material.io/design/color/

В кратце, есть какой-то цвет и для него создаётся рекомендуемый контрастный цвет.

:root {
    --color-primary: #000;
    --coloron-primary: #fff;
}

В качестве дополнительного задания контраста есть идеи использовать доп. параметр -low, -hight

:root {
    --color-primary: #000;
    --coloron-primary: #dddddd ; /* например для текста на фоне с цветом primary */
    --coloron-primary-hight: #ffffff; /* сильноконтрастный цвет */
    --coloron-primary-low: #777777; /* слабоконтрастный цвет */
}

В целом такое именование позволяет добиться предсказуемых результатов при создании темы.

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

.Block {
   background: var(--color-surface);
   color: var(--color-error);
}

И не известно на сколько в новой теме surface и error будут контрастны друг к другу.

upd Пересмотрел ещё раз whitepapper https://github.com/whitepapertools/whitepaper-portal/tree/a6bb170522b470560e3572856cf11b1929e1469a/common.blocks/theme

Идёт разбитие цветовой темы на 2 вида. 1 базовые цвета страницы, 2 контролы (кнопки, чекбоксы, инпуты и т.д.).

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

Плюсы:

• Однозначность использования цветов
• Возможность разрабатывать тему "в вакуме"

Минусы:

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

5. Старые браузеры

Любимый IE... Хоть поддержка по caniuse уже > 90% https://caniuse.com/#search=css-variables он ещё живёт...

Как один из подходов решения этого вопроса есть компромиссный вариант - делать версию с одной темой. Все переменные темы дублировать в :root и через postcss ставить статичные значения.

Этот сегмент получит сильно урезанный вариант оформления... Если это сильно критично то от локальных переменных придётся отказаться и делать стилизацию через каскады.

Либо использовать подходы с css-in-js... Но они не лишены недостатков.

6. Дизайнеры, разработчики и система

Тут конечно есть конфликт интересов... Но имхо, у дизайнера должна быть система, по которой он работает и она должна быть логичной (например http://whitepaper.tools/)

П.Н. Небольшая демка "на коленке" Буду благодарен, если поделитесь своей системой стилизации блоков и именованием переменных.

К примеру есть блок Collapse, у него существует два элемента: Collapse__part & Collapse__item.

На момент инициализации блока хочу разбить его контент таким образом:

//- Из такой структуры (так определено в bemjson)
<div class="collapse">
  <div class="work collapse__item">...</div>
  <div class="work collapse__item">...</div>
  <div class="work collapse__item">...</div>
</div>

//- В такую (модифицировать)
<div class="collapse">
  </div class="collapse__part">
    <div class="work collapse__item">...</div>
    <div class="work collapse__item">...</div>
  </div>
  </div class="collapse__part">
    <div class="work collapse__item">...</div>
  </div>
</div>

C условием того что эти чанки могут быть разной длины(настраиваемый параметр), в данном случае длина составляет 2 элемента(Collapse__item)

Посоветуйте пожалуйста в какой технологии это лучше сделать (в js, bemhtml.js или иным способом), каким образом?

ps. полностью использую среду разработки BEM (rep.: Project-Stub)

Здравствуйте. Подскажите пожалуйста, может ли быть так: Есть блок “родитель”, внутри него есть еще один блок “потомок” и внутри блока потомка есть элемент блока родителя? То есть вот так.

<div class=”parent”>
    <div class=”children”>
      <div class=”parent__elem”></div>
    </div>
</div>

Подскажите как решается данная проблема? У нас имеется класс "header__search-form" который допустим имеет отступ с низу, но как быть если придется перенести блок "search-form" в другое место где ему тоже нужны те же свойства, нужно создавать новый класс для нового окружения, каскадом, добавлением утилитарного класса или как то иначе? вижу 3 варианта

Вариант 1

<div class="header">
    <div class="search-form header__search-form"></div>
</div>

<div class="sidebar">
    <div class="search-form sidebar__search-form"></div>
</div>

<div class="blog">
    <div class="search-form blog__search-form"></div>
</div>

.header__search-form{
    margin-bottom:10px;
}
.sidebar__search-form{
    margin-bottom:5px;
}
.blog__search-form{
    margin-bottom:10px;
}

Вариант 2

<div class="header">
    <div class="search-form mb-10"></div>
</div>

<div class="sidebar">
    <div class="search-form mb-5"></div>
</div>

<div class="blog">
    <div class="search-form mb-10"></div>
</div>

Вариант 3

<div class="header">
    <div class="search-form"></div>
</div>

<div class="sidebar">
    <div class="search-form"></div>
</div>

<div class="blog">
    <div class="search-form"></div>
</div>

.header .search-form {
    margin-bottom:10px;
}
.sidebar .search-form {
    margin-bottom:10px;
}
.blog .search-form {
    margin-bottom:10px;
}

Стандартная ситуация

<body class="body body_fixed">
   <div class="logo">
      LOGO
   </div>
</body>

.logo {
   font-size: 40px;
}
.body.body_fixed .logo {
   80px;
}

Как мне такого рода CSS по папочкам разложить? Как посоветуете наименовать файлы? Что вообще можно сделать чтоб это грамотно сопровождать и deps какой и куда прикладывать. Решил упороться на сборщиках и правильной организации структуры. Настроил сборщики начал тесты проводить потом бац, а что делать со спецефичностью? Хочешь не хочешь но есть моменты когда от неё не уйти.

Добрый вечер. Подскажите пожалуйста, правильно ли организована разметка по БЭМ? Внешняя геометрия и позиционирование блока, а именно padding, position и т.д задаётся через миксы .top-bar__top-lang, .top-bar__top-phone, page__header, footer__copyrights, header__navigation, page__wrapper. Все ли я правильно понял? Можно ли упростить/добавить что либо DOM-узлах?

<body class="page">
    <div class="wrapper page__wrapper">
        <div class="top-bar page__top-bar">
            <div class="top-bar__container">
                <div class="top-bar__row">
                    <div class="top-lang top-bar__top-lang">
                        <ul class="top-lang__list">
                            <li class="top-lang__item">
                                <a href="" class="top-lang__link"></a>
                            </li>
                            <li class="top-lang__item">
                                <a href="" class="top-lang__link"></a>
                            </li>
                            <li class="top-lang__item">
                                <a href="" class="top-lang__link"></a>
                            </li>
                        </ul>
                    </div>
                    <div class="top-phone top-bar__top-phone">
                        <!-- START .top-phone__list -->
                        <ul class="top-phone__list">
                            <li class="top-phone__item">
                                <a href="" class="top-phone__link">p</a>
                            </li>
                            <li class="top-phone__item">
                                <a href="" class="top-phone__link"></a>
                            </li>
                            <li class="top-phone__item">
                                <a href="" class="top-phone__link"></a>
                            </li>
                        </ul>
                    </div>
                </div>
            </div>
        </div>
        <header class="header page__header">
            <div class="navigation header__navigation">
                <nav class="navigation__container">
                    <ul class="navigation__list">
                        <li class="navigation__item">
                            <a href="" class="navigation__links"></a>
                        </li>
                        <li class="navigation__item">
                            <a href="" class="navigation__links"></a>
                        </li>
                        <li class="navigation__item">
                            <a href="" class="navigation__links"></a>
                        </li>
                    </ul>
                </nav>
            </div>
        </header>
        <footer class="footer page__footer">
            <div class="copyrights footer__copyrights"></div>
        </footer>
    </div>
</body>

Приветствую, начинаю изучать БЭМ столкнулся с такой проблемой, как правильно именовать элементы при большой вложенности? Пример:

<div class="profile">
        <div class="profile__slider">
            <div class="profile__slider-slide">
                <div class="btn profile__slider-slide-btn"></div>
                <div class="message profile__slider-slide-message" ></div>
            </div>
            <div class="profile__slider-slide profile__slider-slide_something">
                <div class="btn profile__slider-slide-btn"></div>
                <div class="message profile__slider-slide-message" >
                    <div class="profile__slider-slide-message-bold"></div>
                </div>
            </div>
        </div>
    </div>

Можно использовать данное именование: profileslider-slide-message, которое говорит что это элемент "message" является потомком элемента "slide", который является потомком элемента "slider", который является элементом блока "profile". В данном случае profileslider-slide-message также является элементом блока "profile", хотя это не совсем логично, но обеспечиваться локализация данного элемента, в том плане что он будет уникальным.

В верстке я часто использую псевдоклассы :first-child, :last-child, :nth-child и тд. Они позволяют избежать ошибок при изменении верстки.

Допустимо ли повсеместное использование таких псевдоклассов в БЭМ? Или стоит использовать их только в крайней необходимости, в остальных случая заменяя модификаторами?

Здравствуйте.

Как применять методологию bem с bootstrap-scss при верстке макета ? Меня интересует способы применения какие они есть и какие задачи решает каждый из этих способов.

Как правильно размечать структурно сложные, но одноразовые элементы: бем-блоком или бем-элементом родителя?

Вопрос 1: Предположим имеется какой-нибудь блок карты (card), который в принципе может переиспользоваться в других проектах. Но в разных проектах разные размеры шрифтов. Каким образом поступить: задавать какой-то размер по-умолчанию (например подходящий для текущего проекта) или создавать модификаторы для размеров (или еще как-то)?

Вопрос 2: Предположим есть блок кнопки (button), и в разных местах одного и того же проекта ему задаются разные размеры, это все нужно задавать через модификаторы?

Вопрос 3: Иногда требуется задать отступы от одного блока до другого, как это лучше реализовать (через модификаторы)?

Вопрос 4: Одна и та же кнопка в разных проектах имеет некоторые различия во внешнем виде, но часть стилей одинаковая, в стиль блока запихнуть только общее, а остальное сделать через модификаторы (_theme_a, _theme_b)?

P.S. Новичок в БЭМ, вопросов много, извините.

Знал БЭМ поверхостно - сейчас выделил время чтобы понять полностью. В целом все выглядит логично, кроме миксов. Возьмем пример с описания

<div class="header">
    <!-- К блоку `search-form` примиксован элемент `search-form` блока `header`-->
    <div class="search-form header__search-form"></div>
</div>

Микс header__search-form добавляет некие стили форме поиска. Форма поиска у нас подключается программно модулем. Теперь решили, что форма поиска необходима и в футере. Описываем подключение модуля и там с тем же шаблоном. И у нас (если ни чего не менять) этот микс применится и в футере. Соответственно нам необходимо либо иметь два разных шаблона блока поиска, либо микс выводить по выполнению условия (скажем PHP формирует этот HTML). Что является по сути лишним. Гораздо более логично, понятно и чище будет обойтись без "миксов". Или, точнее, реализовывать их "обычным" способом каскадных стилей.

.header .search-form { color:red; }

Таким образом код блока (включая шаблон) будет абсолютно самостоятелен, в нем не будет необходимости учитывать/проверять контекст, в котором он подключается. Т.е. фраза из статьи

В данном примере мы совместили поведение и стили блока search-form и элемента search-form блока header. Такой подход позволяет нам задать внешнюю геометрию и позиционирование в элементе header__search-form, а сам блок search-form оставить универсальным. Таким образом, блок можно использовать в любом другом окружении, потому что он не специфицирует никакие отступы. Это позволяет нам говорить о его независимости

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

Только начинаю разбираться с БЭМ. Прочитал все что есть на сайте и посмотрел пару роликов, но остались вопросы на самые базовые темы. Вот один из них, касающийся способов модифицирования стилей элементов вложенных блоков:

Предположим, есть блок button:

< div class="button" > < div class="button_ _icon" / > < /div>

.button_ _icon { color: yellow; }

Он является элементом для блока panel

< div class="panel" > < div class = "button panel_ button" > < div class="button _icon" /> < /div> < /div>

Предположим, мне надо поменять цвет у button__icon только в панели, но не задеть его в остальных местах. Как это сделать правильно?

1. Примиксовывать к button_ icon panel _button-icon. Это может привести к изменению кода блока button, если он не подразумевал возможность примиксовывать к иконке другие классы (например, мы используем React), что противоречит БЭМ.
2. Использовать вложенный селектор .panel .button_ _icon { color: red; }. Это увеличивает связанность компонент и зависимость от реализации button'а. Ну и в обоих этих вариантах panel в принципе не должен обращаться да и знать про элементы чужого блока.
3. Добавить модификатор button_ _icon_color_red для иконки. Опять же потребуется изменение кода для кнопки. И реализация сильно усложнится, если вложенность будет бОльшая - например, не во всех панелях у кнопки другой цвет, а только в панелях, которые лежат в header. Прокидывать модификатор через всю иерархию - напрягает. Как правильно?

Обучаю студентов вёрстке по методологии БЭМ. Хочу автоматизировать простейшую проверку именования по методологии: на пркоммит-хук повесить линтер, который будет проверять pug-разметку (ну или компилировать ее в html и проверять уже его) на предмет соблюдения методологии.

Есть какие-то готовые решения, которые у меня не получилось загуглить? В какую сторону смотреть?

Всем привет ! Я только недавно начал глубже погружаться в БЭМ-методологию (до этого использовал только БЭМ-нейминг). Мне очень понравилась эта концепция и хотелось бы полностью внедрить ее в свой воркфлоу. Однако, т.к. у меня недостаточно опыта и я довольно поверхностно знаю JavaScript, мне не хватает знаний чтобы запилить свой "велосипед" для Gulp4 и/или Webpack4. А готовые решения вроде bem-tools, enb и других специфических решений мне не подходят из-за своей перегруженности и как мне кажется сложности. Я не говорю что это так и есть, это справедливо и субъективно лично для меня.

Хотелось бы иметь возможность подтягивать данные в pug-шаблоны из data.json-файла или аналогичного data.js, а также декларативно определять структуру БЭМ-боков с учетом соответствующих зависимостей.

Если совсем коротко, то нужно вот из такой структуры:

app
│   ├── assets
│   │   ├── fonts
│   │   ├── images
│   │   └── libs
│   ├── blocks
│   │   ├── common.blocks
│   │   │   ├── footer
│   │   │   └── header
│   │   │       ├── header.js
│   │   │       ├── header.pug
│   │   │       ├── header.scss
│   │   │       ├── img
│   │   │       └── nav-menu
│   │   │           ├── img
│   │   │           │   └── background.jpg
│   │   │           ├── nav-menu.js
│   │   │           ├── nav-menu.pug
│   │   │           └── nav-menu.scss
│   │   ├── desktop.blocks
│   │   └── touch.blocks
│   ├── pages
│   │   ├── about
│   │   │   ├── about.js
│   │   │   ├── about.pug
│   │   │   └── about.scss
│   │   ├── gallery
│   │   │   ├── gallery.js
│   │   │   ├── gallery.pug
│   │   │   └── gallery.scss
│   │   └── home
│   │       ├── home.js
│   │       ├── home.pug
│   │       └── home.scss
│   └── templates
│       ├── custom.pug
│       └── default.pug

получить на выходе вот такую:

.
├── about.html
├── assets
│   ├── fonts
│   │   ├── font1
│   │   └── font2
│   ├── images
│   │   └── sprites
│   │       ├── png
│   │       └── svg
│   ├── scripts
│   │   ├── about.min.js
│   │   ├── common.min.js
│   │   ├── gallery.min.js
│   │   └── home.min.js
│   └── styles
│       ├── about.min.css
│       ├── common.min.css
│       ├── gallery.min.css
│       └── home.min.css
├── gallery.html
└── home.html

Мне не принципиально на чем делать сборку, будь-то Gulp, Webpack или их совместное использование, главное получить ожидаемый и предсказуемый результат. Надеюсь, я доступно изъяснялся и смог донести свою мысль. Какие будут мысли на этот счет ? :) Заранее всем признателен.

з.ы. Естественно, прежде чем оставлять свой вопрос здесь я шерстил по сети в поисках готовых решений, однако в одних случаях разобраться мешало отсутствие документации, в других - неактуальность самой информации, в иных - не хватало моей профессиональной компетенции. з.з.ы. В Ютубе я натыкался на пару видео, но если честно, изложенная там информация расчитана далеко не на новичков. Пользуясь случаем, хочу попросить ответственных ребят из Яндекса обновить учебные видеоматериалы и записать воркшопы по сборке БЭМ-проектов на Gulp4 и Webpack4 с учетом реалий 2019 года. Я думаю, не одна сотня людей ждет подобного материала. Всем спасибо.

Добрый день. Планируется ли обновлять эту технологию, так как она довольно интересно смотрится, но не поддерживает PostCSS. Если не планируется, то возможно у кого-то есть нечто подобное, был бы благодарен!

Решил создать собственный блок. Назвал его usual. Но при добавлении mod к нему ничего не происходит. Единственное, что применяется - это tag()(). Вот, что я пишу в usual.bemhtml(скрин) Вот что на выходе:

Следую инструкциям описанным в этой статье - https://habr.com/company/yandex/blog/251473/ При сборке и старте проекта(npm start или enb server) возникает ошибка в borshik'е При этом проект собирает все, но при изменении чего-либо в файлах не реагирует и не перезагружает страницу.

TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type undefined
    at assertPath (path.js:39:11)
    at Object.dirname (path.js:651:5)
    at res.__constructor (C:\Users\Admin\Desktop\currebt\secondproject\node_modules\borschik\lib\tech.js:87:47)
    at new res (C:\Users\Admin\Desktop\currebt\secondproject\node_modules\borschik\node_modules\inherit\lib\inherit.js:123:43)
    at res.createFile (C:\Users\Admin\Desktop\currebt\secondproject\node_modules\borschik\lib\tech.js:24:24)