[B~Vladi]

А по моему вполне реально такой парсер написать.

Основываясь только на именах - реально. Но всплывает много кейсов. Например, откуда парсер будет знать, что возвращает require? Конечно, можно ограничиваться именами, но как-то мало от этого пользы получается.

Если бы ты развил мысль на наглядном абстрактном примере... Т.е. код и полученная схема.

Ещё для такого парсера нужно брать какой-нибудь готовый статический анализатор. Ну и без поддержки JSDoc толку будет мало.

Цены бы не было такому парсеру, если бы он генерировал алгоритм наподобие этого:


Есть ещё один важный момент. Что бы диаграмма была более читабельной, необходимо иметь возможность управлять логикой её генерации. Например здесь описана такая возможность, в разделе "Changing arrow direction". По опыту могу сказать, что без этого будет получаться, скажем так, не то. Например:

/*
@startuml
title The architecture of the site

skinparam componentStyle uml2
skinparam component {
  BorderColor<<P>> #FF6655
}

component "Template Engine" as TEN <<P>>
component "Builder" as Builder <<P>>
component "Router" as Router <<P>>
component "Web Server" as Server
component "Data Base,\nCache" as DB

interface "HTTP(S)" as HTTP

Server -r- HTTP

HTTP .r.> Router: Proxy

package "Project" {
    component "Static" as Stat
    component "Templates" as TMPL
    component "Applications" as Apps

    interface "Data\naccess" as API

    TMPL .r.> API
    TMPL .d.> Builder: Configure

    Apps -l- API
    Apps .r.> DB
}

Router -r-> TEN
TEN -d-> TMPL: Rendering
Builder --> Stat: Build
HTTP .d.> Stat: Proxy
TMPL -u-> HTTP

note right of Builder: It works once at initialization

@enduml
*/

Результат:


Здесь практически для каждой связи используются указания направления (.d. - down, -r- - right и т.д.). Вот, что будет без них:

/*
@startuml
title The architecture of the site

skinparam componentStyle uml2
skinparam component {
  BorderColor<<P>> #FF6655
}

component "Template Engine" as TEN <<P>>
component "Builder" as Builder <<P>>
component "Router" as Router <<P>>
component "Web Server" as Server
component "Data Base,\nCache" as DB

interface "HTTP(S)" as HTTP

Server -- HTTP

HTTP ..> Router: Proxy

package "Project" {
    component "Static" as Stat
    component "Templates" as TMPL
    component "Applications" as Apps

    interface "Data\naccess" as API

    TMPL ..> API
    TMPL ..> Builder: Configure

    Apps -- API
    Apps ..> DB
}

Router --> TEN
TEN --> TMPL: Rendering
Builder --> Stat: Build
HTTP ..> Stat: Proxy
TMPL --> HTTP

note right of Builder: It works once at initialization

@enduml
*/

Результат:


Читабельность явно пострадала.

Ну и ещё один момент. PlantUML может генерировать схемы разного типа. Парсер же кода - одного.

Но всё вышесказанное никак не должно восприниматься как попытка отговорить от этой затеи. Я лишь хочу показать подводные камни, которые могут возникнуть. Их скорей всего будет больше, я лишь привел те, что первыми пришли в голову.
В любом случае мысль интересная, я бы понаблюдал как минимум.