Open tadatuta opened 10 years ago
tadatuta
commented
10 years ago Конспект встречи про https://github.com/mdevils/analyze и чуть-чуть будущее bem-tools@v2 (в самом конце).
// cc @mdevils @arikon @SevInf @andrewblond @tormozz48 @veged @mursya @zxqfox @scf2k
qfox
commented
10 years ago Есть предложение, что нужно делать tool-chain из модулей с API, решающих конкретные задачи. И в этом контексте есть идея, что можно вынести из ENB ядро (task + node + target), для решения задачи сборки без привязки к предметной области.
А это не получится нечто типа apw? Сорри, если вопрос дилетансткий. Мои мысли на этот счет — чтобы знать оптимальный по времени алгоритм сборки нужно заранее строить весь план. Может быть в два прохода, если нужна (например, на очень больших проектах) достройка плана. Впрочем, это все слова.
@mdevils Марат, если вынести из ENB ядро сборки и node&target свести к task — скорость сборки сильно пострадает? Вообще, звучит логично, конечно.
mdevils
commented
10 years ago @zxqfox Пострадает простота настройки сильно, в основном. Сейчас в технологиях используется много дефолтных значений относительно нод, в которых они.
blond
commented
10 years ago @arikon, у тебя вроде были мысли про то как оставить только task, чтобы API не пострадало, можешь эти мысли тут написать?
qfox
commented
10 years ago @mdevils Если сделать прокси с текущим апи, который будет где-то внутри работать со сборщиком, то останется текущая настройка as is. Разве нет?
arikon
commented
10 years ago @zxqfox @mdevils Мне тоже кажется, что можно небольшими усилиями сделать надстройку над task, которая будет привносить в предметную область два понятия — node и target.
@andrewblond Это и есть мои мысли.
arikon
commented
10 years ago @mdevils @andrewblond @zxqfox Что касается идеи оставить в предметной области про сборку только таски.
Во-первых, это очень близко к тому, что есть в grunt (можно освежить понимание, как там и годится ли).
Во-вторых, есть проект node-task (правда, давно не было апдейтов), который хорошо (на мой взгляд) описывает эту предметную область в спеках. В grunt@0.5.x разработчики хотели поддержать node-task. Пруфлинк.
Analyze — пакет, который строит объектную структуру проекта. Первая цель — генерация UML-диаграмма классов и взаимодействий, которая бы не протухала.
Анализ структуры проекта и связей между ними.
Работает на провайдерах.
Подходит для BEViS-проектов, но сама структура не слишком завязана на BEViS, т.к. используются достаточно абстрактные сущности.
Но провайдер jsdoc работает на BT-шаблонах.
Есть провайдер для модульной системы, написанной dfilatov.
Есть дополнения.
CLI Единственная команда report — загружает конфиг .analyze.js (если есть), вынимает оттуда директории проекта, анализиует проект (все файлы с расширением js, но не test.js). Каждый файл обрабатывается отдельно.
Каждый провайдер возвращает данные, на основе которых формируется общий результат.
Пост-обработка — построение зависимостей (между классами).
Набор зависимостей — это отдельная сущность.
Обработка:
На данном эта получаем Объектная модель (инстанс Project) и инстанс ErrorLog (включает указание на строку с ошибкой)
Настройка node.js-модуль экспортирует функцию, которая настраивается конфигуратором.
Планы на будущее Команда репорт не будет иметь предустановленных стратегий анализа (стратегии будут описываться отдельно). Будет возможность в js-файле описывать стратегии.
Хочется: builder (сделать настраиваемый, который бы можно было переопределять) стратегии (какой проект) вызывает процессоры про каждую сущность
file-analyzer -> js-file-analyzer
История разработки
BT-json -> MD + вставки ```BT-json, примеры и документация по js из jsdoc.
BEViS-doc-builder включает две технологии для генерации одно- и многостраничной (для Dash) документации.
Есть предложение, что нужно делать tool-chain из модулей с API, решающих конкретные задачи. И в этом контексте есть идея, что можно вынести из ENB ядро (task + node + target), для решения задачи сборки без привязки к предметной области.
У Марата нет уверенности, что устройство на node&target — это хорошо, т.к. понятие ноды излишне конкретное. Для сборщика общего назначения есть смысл оставить только target-ы (таски).
node - это папка (частный случай task) target - файлы либо папки, которые лежат в node task - как в Гранте, но без параметров (именованная задача, которая может использовать другие task).