Directories instead of files
Yeti-or opened this issue · 8 comments
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 возвращать, который внутри кто-то другой расчехлит.
Если не согласен, давай аргументы. Аналогия с PostCSS какая-то вообще не к месту ;)
VinylDirectory
норм, если при этом не надо идти на файловую систему, чтобы узнать что внутри этой директории. А в виниле есть директории?
Ну и я бы не постеснялся возвращать VinylFile
для директории.
Моя идея такая, мы нашли файлы или директории, которые по неймингу и схеме внутри уровня являются сущностью. Всё, на этом моменте нужно остановится.
Как в случае с файлом нам не надо читать и парсить его содержимое, так и в случае с директорией этого делать не надо.
@zxqfox ну или расскажи зачем нам читать какие файлы есть в директории и стримить это?
Не не, читать не надо. Согласен, что Stream<File>
плохая идея.