[Proposal] Visualize dependency graph.

[deebloo]

Problem

I have a large number of build commands and packages that depend on each other and I would like to visually inspect these relationships to help with debugging and documentation.

Proposed solution

I would love a command like "wireit --visual" that would show you the graph for the specific command being run, and if no command is being run for the whole project. This could be setup to work both between separate packages and between different commands

graph TD;
    common:build-->core:build;
    common:build-->common:css;
    feature1:build-->common:build;
    feature2:build-->common:build;
    feature2:build-->feature1:build
    feature1:test-->feature1:build

The above shows the sort of information I would want to know. The name of the package and the name of the build script. Here is very simple POC that uses the wireit Analyzer and creates a visualization with mermaidjs. It might also make sense to make this part of the vs-code extension instead of an option in the CLI

https://github.com/deebloo/wireit-visualizer

[peschee]

I would love for this to be part of the CLI, effectively making it available to all users, including those NOT relying on Visual Studio Code.

[deebloo]

Could easily be both. I'm going to keep working out ideas in that separate package to see if it is something worth bringing into wireit proper or should just remain something that runs on top.

[peschee]

I think this could easily exists as something separate on top 👍

[deebloo]

@rictic do you think wireit would be willing to expose certain bit of the wireit internals? Namely the analyzer?

[rictic]

@aomarks can comment on exposing the analyzer.

I'm gonna see about cleaning up #652 to land. I think it'd be awesome to have a mermaid graph visualizer in the VSCode plugin. Probably not in the main wireit CLI since we want to keep that super small and low dependency, but the VSCode plugin doesn't need to be particularly small

[deebloo]

I think that makes a lot of sense based on stated goals. Glad to see it is something being thought about!

[deebloo]

@rictic I will say that mermaid does have a max number of nodes, I recently updated my little tool to use graphviz instead. https://github.com/deebloo/wireit-visualizer/issues/8

[aomarks]

@rictic do you think wireit would be willing to expose certain bit of the wireit internals? Namely the analyzer?

A downside would just be that we'd need to start tracking semver for the analysis API. Just curious what other use cases you have in mind? If we just exposed an API that produced mermaid, would that be sufficient? Or do you have some other/more advanced ideas in mind?

[deebloo]

I would want to be able to generate whatever visual I like. It may not be necessary since the way that dependencies are defined is static. I was also looking at build a GUI that would help you define, run and debug scripts. (for example I can generate a graph that shows you which tasks are being run in realtime and also help you identify bottlenecks in your build graph) Using the built in analyzer would just make it so I don't have to implement my own.

[aomarks]

If we published the analyzer as a separate package then we could bump breaking changes to it on a faster cadence than wireit itself. The thing I would be concerned about is that we want to be able to iterate quickly on the analyzer API without having to publish a semver breaking change to the main wireit package that the vast majority of users wouldn't care about (because it will slow adoption because major changes are slower for people to upgrade to).

[deebloo]

As long as wireit task configuration stays static I think I will be fine with my custom analyzer. Would it be reasonable to have a published but unstable analyzer API? keep it internal but publish it with a warning? then you wouldn't have to worry about moving quickly and breaking something. Although I am sure no matter how many warnings you put there would still be issues filed.

[deebloo]

another option would be to expose the graph through just JSON. So don't expose the Analyzer itself, but expose a data structure with vertices/nodes and edges.