Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Visualize dependency graph. #977

Open
deebloo opened this issue Nov 20, 2023 · 12 comments
Open

[Proposal] Visualize dependency graph. #977

deebloo opened this issue Nov 20, 2023 · 12 comments

Comments

@deebloo
Copy link

deebloo commented Nov 20, 2023

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
Loading

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

@deebloo deebloo changed the title [Proposal] Allow view and export of dependency graph. [Proposal] Visualize dependency graph. Nov 20, 2023
@peschee
Copy link
Contributor

peschee commented Nov 25, 2023

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
Copy link
Author

deebloo commented Nov 25, 2023

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
Copy link
Contributor

peschee commented Nov 25, 2023

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

@deebloo
Copy link
Author

deebloo commented Dec 1, 2023

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

@rictic
Copy link
Member

rictic commented Dec 19, 2023

@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
Copy link
Author

deebloo commented Dec 19, 2023

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

@deebloo
Copy link
Author

deebloo commented Dec 19, 2023

@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

@aomarks
Copy link
Member

aomarks commented Dec 19, 2023

@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
Copy link
Author

deebloo commented Dec 19, 2023

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
Copy link
Member

aomarks commented Dec 19, 2023

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
Copy link
Author

deebloo commented Dec 19, 2023

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
Copy link
Author

deebloo commented Dec 20, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants