Open nicothin opened 7 years ago
Ответ на вопрос 2. Если поискать https://github.com/bem/project-stub/search?q=merged&type=Issues&utf8=%E2%9C%93 то можно найти зачаточную историю о добавлении и удалении...
Протестировал работает, немного поправил, смотри: https://github.com/bem/project-stub/compare/0c15a15da1ad0240d9d449f2c8cd34538d192eb5...ilyar:example-merged-enb?expand=1
@ilyar как я понимаю, получившиеся js и css файлы — это простая склейка соотв. файлов страниц (бандлов) — http://take.ms/ozs4J — скрин для двух страниц. гарантировать очередность в такой ситуации будет непросто...
Это не простая склейка, то что на скрине скорей всего ошибка.
смотри добавил пару страниц и блоков https://github.com/ilyar/project-stub/commit/f98604c84b3b3b7e94820a432e593b219e3dabc1
index
содержит b0
и b1
page1
содержит b0
и b1
и b2
⇒ some
(b2
ожидает, что до него будет блок some
зависимость mustDeps
)
page2 содержит
b0и
b3`
вжих
и готово https://github.com/bem/project-stub/commit/9182785ed4afa6b8d0a0ba74a1a6b010f993792e
merged-декларация:
exports.blocks = [
{
"name": "b0"
},
{
"name": "b1"
},
{
"name": "b2"
},
{
"name": "b3"
}
];
merged-зависимости:
exports.deps = [
{
"block": "b0"
},
{
"block": "b1"
},
{
"block": "some"
},
{
"block": "b3"
},
{
"block": "b2"
}
];
merged-результат:
.b0 {}
.b1 {}
.some {} /* как и требовалось до b2 */
.b3 {}
.b2 {}
Bonus: script watch (LiveReload)
+ "browser-sync": "^2.18.5",
},
"scripts": {
+ "watch": "enb server & browser-sync start --files \"*.blocks/**/*, *.bundles/**/*.bemjson.js\" --proxy 0.0.0.0:8080",
@ilyar спасибо! п.с.: автозагрузка на винде не заводится — браузерсинк стартует только после остановки enb-сервера ))) я пока планирую использовал галп — копировать JS и CSS из merged-бандла, HTML из прочих бандлов и доп. файлы в папку сборки, в ней же и браузерсинк пускать.
Да.
Стартует enb сервер, работает, в браузере на локалхосте показываются бандлы, по изменению разметки не происходит ничего, нужно обновлять страницу, чтобы увидеть.
Останавливаю enb, вижу в консоли вывод браузерсинка, типа он стартовал на 3000 порту ))
ну и --proxy 127.0.0.1:8080
у меня вместо нулей.
Случайно дропнул свой вопрос: "Интересно, расскажи подробнее, запускал через npm run watch
?"
Уверен, что до запуска npm run watch
порт свободен и enb не запущен?
оба упомянутых порта (3000 и 8080) свободны, если верить netstat
enb не запущен
https://github.com/nicothin/project-stub — экспериментирую в этом репозитории.
Уверен, что меняешь прописанные в --files
файлы?
Абсолюно.
Но какая разница что я меняю, если в момент изменений браузерсинк еще не заупщен? ))
Я ж говорю, он стартует только после остановки ENB.
Словно там &&
написано, а не &
.
Ааа... понял, наверное это особенность window. Вижу два варианта:
POSIX совместимость choco install babun -y
и попробуй еще раз.
Или попробуй разбить скрипт на два (старт enb
и отдельно browser-sync
), а точнее для project-stub
уже есть npm start
запускаем и в отдельной консоле npm run bsync
или просто browser-sync start --files "*.blocks/**/*, *.bundles/**/*.bemjson.js" --proxy 0.0.0.0:8080
.
Еще может будет полезна тема: enb LiveReload или аналоги.
Рекомендую пробовать именно "POSIX совместимость", но нет абсолютной уверенности, что это сработает, но попробовать стоит.
Если будет работать, это может решить другие особенности windows-платформы.
Перелезать с гитбаша на бабун... Ну, не знаю...
Если есть другие способы добиться "POSIX совместимость" на windows-платформе, буду рад узнать.
В общем, не работает автообновление в винде, как не бейся.
Выход только один ( и относительно паршивый): собирать все в какую-то папку (сам буду галпом пробовать) и запускать enb make
на каждое изменение файлов, после чего снова копировать в папку сборки и по этому факту уже обновлять браузерсинком.
Мейк у меня даже в самом простом случае — 2 сек, что в «непростом» будет — подумать страшно :(
Как вариант, попытаюсь завтра поставить таки на свою Win 10 режим разработчика и консоль убунты.
@nicothin «даже если вас съели, у вас есть два выхода» ;)
В данном случае вариантов решения гораздо больше. А заодно и способов оптимизации, чтобы ускорить сборку. Но опять-таки, чтобы мочь выбрать самый подходящий, мне хорошо бы понимать задачу целиком. Я прочитал описание из https://ru.bem.info/forum/1207/#comment-271090255, но этого все равно недостаточно, чтобы сложить полную картину.
Несколько наводящих вопросов:
Зачем нужна именно такая структура? Какую проблему она решает по отношению к той, что предполагается из коробки? Например, если она требуется для деплоя, то к ней можно приводить один раз перед деплоем, а в процессе разработки оставить исходную.
Если есть причины использовать такую схему и при разработке, то стоит определиться, нужно ли каждый раз пересобирать merged bundle или в девелопменте достаточно только текущего, а все в кучу опять-таки собирать лишь в последний момент — это должно заметно сказаться на скорости сборки.
Если собираться на gulp
, то финальная структура выражается с помощью gulp.dest()
и может быть совершенно произвольной.
Если же предпочтительна сборка на ENB
, то есть технология file-copy, которая позволяет копировать файлы по произвольному пути как один из шагов сборки.
Если желание получить описанную файловую структуру происходит от необходимости получить определенную структуру урлов, то эту задачу можно решить роутингом на уровне веб-сервера (nginx, node.js, etc.)
browser-sync
нужен именно в таком исполнении или любая реализация live reload
подойдет?
enb make
занимает много времени на инициализацию, если его поднять как процессе (а-ля enb server
, то каждая пересборка будет заметно быстрее.
Если в сборке присутствуют всякие «дорогие» с точки зрения времени выполнения шаги, то можно ли часть не выполнять в процессе девелопмента или закешировать?
Это, конечно, далеко не все вопросы, которые могут помочь собрать оптимальный конфиг, так что буду рад максимальному количеству подробностей.
Впрочем, базовый универсальный вариант вотчера с лайв релоадом давно пора добавить в bem-express
, думаю, сделаю это завтра, возможно, это можно будет использовать как частичный ответ.
Протестировал на windows способ watch (LiveReload), это не работает, POSIX совместимость либо не достижима для windows, либо я не умею готовить.
Но думаю есть решение concurrently:
npm install -g concurrently
npm install -g browser-sync --msvs_version=2013 # специально для пользователей windows-платформы, но возможно и без этого флага будет работать
concurrently "enb server" "browser-sync start --files \"*.blocks/**/*, *.bundles/**/*.bemjson.js\" --proxy 0.0.0.0:8080"
Полностью протестировать данное решение не получилось, возможно это проблема виртуалки на которой все делал.
В общем думаю будет работать.
@ilyar
перевел винду в режим разработчика, поставил подсистему убунту и использовал убунтовский баш для вызова npm run watch
(который "watch": "enb server & browser-sync start --files \"*.blocks/**/*, *.bundles/**/*.bemjson.js\" --proxy 0.0.0.0:8080"
):
nicothin@NICWIN10 /mnt/d/projects/project-stub
% npm run watch
> bem-project-stub@2.0.0 watch /mnt/d/projects/project-stub
> enb server & browser-sync start --files "*.blocks/**/*, *.bundles/**/*.bemjson.js" --proxy 0.0.0.0:8080
/mnt/d/projects/project-stub/node_modules/dev-ip/lib/dev-ip.js:21
var networkInterfaces = require("os").networkInterfaces();
^
Error: EINVAL: invalid argument, uv_interface_addresses
at Error (native)
at getIp (/mnt/d/projects/project-stub/node_modules/dev-ip/lib/dev-ip.js:21:43)
at Object.<anonymous> (/mnt/d/projects/project-stub/node_modules/browser-sync/lib/utils.js:4:38)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
npm ERR! Linux 3.4.0+
npm ERR! argv "/usr/bin/nodejs" "/usr/bin/npm" "run" "watch"
npm ERR! node v6.9.4
npm ERR! npm v3.10.10
npm ERR! code ELIFECYCLE
npm ERR! bem-project-stub@2.0.0 watch: `enb server & browser-sync start --files "*.blocks/**/*, *.bundles/**/*.bemjson.js" --proxy 0.0.0.0:8080`
npm ERR! Exit status 1
То есть, по крайней мере, в виндовской убунте это тоже не работает. Сейчас попробую второй предложенный вами способ.
@ilyar предпочитаю иметь зависимости внутри проекта :)
npm i -D browser-sync concurrently
Для винды пришлось немного поменять команду. Итого в package.json
:
"watch": "concurrently \"enb server\" \"browser-sync start --files '*.blocks/**/*.css, *.bundles/**/*.bemjson.js' --proxy 127.0.0.1:8080 --no-inject-changes\" -k",
Браузерсинк пытается инжектить стили, пришлось добавить --no-inject-changes
— автоперезагрузка при изменении стилей :( (ну, хоть не руками)
Еще перспективный вариант это docker
Docker контейнер для проектов на БЭМ от @nejtr0n
Супер, вжих и готово project-stub внутри.
@tadatuta давайте в том же топике продолжим, чтобы темы не смешивать. Отвечу там на вопросы.
Клонирую себе project-stub, ставлю зависимости, добавляю вторую страницу. https://ru.bem.info/toolbox/enb/enb-bem-techs/build-merged-bundle/ — копипастю код
.enb/make.js
(исходный — комментирую) вызываюnode_modules/.bin/enb make
получаюError: Cannot find module 'enb-css/techs/css'...
ставлю https://github.com/enb/enb-css как зависимость, вызываюnode_modules/.bin/enb make
получаюError: file not found: D:\projects\project-stub\desktop.bundles\contacts\contacts.bemdecl.js...
Немного странно выходит: чтобы собрать merged-бандл мне нужно сначала собирать обычный (в моем случае — постраничный), потом менять код
.enb/make.js
? (Данублин!)Вопросы:
node_modules/.bin/enb make
с разными конфигами? (.enb/make.js
отдельно, какой-нибудь.enb/build.js
) отдельно). Если да — как?.enb/make.js
?