[Proposal] Visualize dependency graph. about wireit HOT 12 OPEN

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

from wireit.

@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

from wireit.

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.

from wireit.

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.

from wireit.

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

from wireit.

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

from wireit.

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

from wireit.

@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?

from wireit.

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.

from wireit.

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).

from wireit.

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.

from wireit.

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.

from wireit.