Analyze — пакет, который строит объектную структуру проекта. Первая цель — генерация UML-диаграмма классов и взаимодействий, которая бы не протухала.

Анализ структуры проекта и связей между ними.

Работает на провайдерах.

Подходит для BEViS-проектов, но сама структура не слишком завязана на BEViS, т.к. используются достаточно абстрактные сущности.

Но провайдер jsdoc работает на BT-шаблонах.

Есть провайдер для модульной системы, написанной dfilatov.

Есть дополнения.

CLI Единственная команда report — загружает конфиг .analyze.js (если есть), вынимает оттуда директории проекта, анализиует проект (все файлы с расширением js, но не test.js). Каждый файл обрабатывается отдельно.

Каждый провайдер возвращает данные, на основе которых формируется общий результат.

Пост-обработка — построение зависимостей (между классами).

Набор зависимостей — это отдельная сущность.

Обработка:

1. Фильтры (из общей структуры остается какой-то необходимый сабсет) source target show — общая картина, все связи (source + target)
2. Валидация (не связан со структурой, указывает на какие-то несоответствия, например, обязательное наличие return type) ErrorLog — в него пишут провайдеры и валидаторы Валидаторы имеют настройки в CLI.

На данном эта получаем Объектная модель (инстанс Project) и инстанс ErrorLog (включает указание на строку с ошибкой)

1. Репортер

Настройка 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).