bem
Directories instead of files
What if we have something like this:
common.blocks/icon/
├── _type
│ ├── icon_type_arrow.assets
│ │ ├── arrow-b.svg
│ │ ├── arrow-l.svg
│ │ ├── arrow-r.svg
│ │ └── arrow-t.svg
│ ├── icon_type_arrow.css
│ ├── icon_type_close.assets
│ │ └── close.svg
│ └── icon_type_close.css
├── icon.bemhtml.js
├── icon.bh.js
├── icon.css
├── icon.deps.js
so we have .assets technology. Now we expect only files like icon.css or icon.js. What should we give to our users?
bundle.src({
tech: 'assets',
extensions: ['assets']
}).pipe(' What we have here?')
Well, I guess we should pass something like Stream with Files instead of single File.
Well, I guess we should pass something like Stream with Files instead of single File.
no
What do you think?
bem-walk should return stream with *.assets dirs only (without inner files).
The files in *.assets dirs is the internal implementation of assets technology. And we don't need to know anything about it.
Tech-plugins should decide how handle this dirs. Is it the same as PostCSS should know how to read and parse CSS.
Ты не понял, если мы для файлов будем возвращать File, а для директорий — неведомое что-то, будет неконсистентность ;-)
Вопрос не про bem-walk, а про gulp-bem. Раскрывать не надо — нужно просто VinylDirectory или Stream<File> возвращать, который внутри кто-то другой расчехлит.
Если не согласен, давай аргументы. Аналогия с PostCSS какая-то вообще не к месту ;)
VinylDirectory норм, если при этом не надо идти на файловую систему, чтобы узнать что внутри этой директории. А в виниле есть директории?
Ну и я бы не постеснялся возвращать VinylFile для директории.
Моя идея такая, мы нашли файлы или директории, которые по неймингу и схеме внутри уровня являются сущностью. Всё, на этом моменте нужно остановится.
Как в случае с файлом нам не надо читать и парсить его содержимое, так и в случае с директорией этого делать не надо.
@zxqfox ну или расскажи зачем нам читать какие файлы есть в директории и стримить это?