Реврайт стандартных урлов bem server с помощью прокси на nginx

Форум /

По-умолчанию bem server ожидает следующую структуру для собранных файлов страниц:
[project-root]/pages-desktop/[pagename]/[pagename].html

Одним из вариантов обеспечения ЧПУ может служить такой конфиг для nginx:

server { listen 80; server_name ~^localhost$; location / { proxy_pass http://localhost:8080; } # /favicon.ico rewrite ^/favicon.ico$ /pages-desktop/favicon.ico last; # / => /pages-desktop/index rewrite ^/(\?.*)?$ /pages-desktop/index/index.html$1 last; rewrite ^/_(?:\w+)\.(js|css|\w+\.css)(\?.*)?$ /pages-desktop/index/_index.$1$2 last; # /page => /pages-desktop/page/page.html rewrite ^/(\w+)/(\?.*)?$ /pages-desktop/$1/$1.html$2 last; # css, js rewrite ^/(\w+)/_(?:\w+)\.(js|css|\w+\.css)(\?.*)?$ /pages-desktop/$1/_$1.$2$3 last; # add final slash to url rewrite ^/([^?/.]+)(\?.*)?$ /$1/$2 permanent; rewrite ^/([^?]+/[^?/.]+)(\?.*)?$ /$1/$2 permanent; }

Было	Стало
http://localhost:8080/pages-desktop/index/	http://localhost/index
http://localhost:8080/pages-desktop/some-page/some-page.html	http://localhost/some-page
http://localhost:8080/pages-desktop/some-page/some-page.html?param1&param2	http://localhost/some-page?param1&param2
http://localhost:8080/pages-desktop/some-page/some-page.css	http://localhost/some-page.css
http://localhost:8080/pages-desktop/some-page/some-page.css?param1&param2	http://localhost/some-page.css?param1&param2
http://localhost:8080/pages-desktop/some-page/some-page.ie.css	http://localhost/some-page.ie.css
http://localhost:8080/pages-desktop/some-page/some-page.js	http://localhost/some-page.js
http://localhost:8080/pages-desktop/favicon.ico	http://localhost/favicon.ico

andrewblond

Спасибо за совет! Но вам не кажется, что по умолчанию технология должна ожидать наиболее логичной и, как ни странно, наиболее ожидаемой структуры (в приведённом вами примере, структура "Стало", на мой взгляд, таковой и является). Деление на десктопный/мобильный/планшетный/и т.д. довольно условно и может быть удобно в частных случиях, но никак не в общем.

Получается, даже, некое навязывание конкретной реализации, что несхоже с традициями БЭМ-идеологии (например, при разработке с побощью БЭМ каждый может решать сам использовать ли префиксы типа "b-", "i-" или нет).

Интересно услышать мнение разработчиков БЭМ по этому поводу.

tadatuta

Технология по-умолчанию представлена в колонке «Было». Она логична с точки зрения методологии и удобна для разработки, но проект в продакшене должен иметь человекопонятные красивые урлы.
«Стало» — это результат действия приведенного в посте конфига. Разумеется, его можно невозбранно, как сказал бы Мицгол, менять под нужны вашего конкретного проекта и он является лишь примером.
Что касается pages-desktop, то по-умолчанию bem make ожидает pages* (pages, pages-desktop, pages-mobile, pages-touch и т.п.) в качестве уровня бандлов и это поведение можно полностью настраивать в .bem/make.js через


MAKE.decl('Arch', {
    bundlesLevelsRegexp: /регулярное выражение/,
});

В Яндексе принято деление на платфомормы и этот подход в т.ч. применяется для библиотек блоков (например, bem-bl/blocks-desktop), но, как вы верно заметили, это все остается на откуп разработчикам и, как методология, так и инструменты не навязывают этого разделения.

andrewblond

Теперь всё стало понятно. И ожидание именно pages*, а не как показалось ранее только pages-desktop выглядит вполне логичным.

Спасибо вам, ребята, за клёвые и логичные тулзы

veged

такие вещи должно быть не сложно сделать в .bem/make.js -- просто описать новые узлы, которые позависеть от соответствующих существующих узлов

peimei

Такие узлы будут триггерить сборку, но в браузер отдавать будет нечего.

veged

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

peimei

Как вариант, можно написать такой библиотечный класс, типа AliasNode, который будет параметризоваться целью-зависимостью и опционально именем файла (для случаев, когда нода-зависимость собирает несколько файлов), который нужно отдать по завершению сборки.

https://github.com/bem/bem-tools/issues/218

qfox

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

Правда, практической пользы, ведь, не сильно много