mbtproject / mbt

The most flexible build tool for monorepo
https://github.com/mbtproject
Apache License 2.0
219 stars 35 forks source link

Visualise the entirety of a filtered sub-graph #115

Open buddhike opened 6 years ago

buddhike commented 6 years ago

When used with --name and --graph options in describe command, this feature will emit a dot graph containing the dependents and dependencies of the filtered modules.

They should be colour coded and grouped for easy identification of relationship.

buddhike commented 6 years ago

@ojizero Do you think ApplyFilters should return a more detailed information to support operations like this or is there a better way to do this?

ojizero commented 6 years ago

@buddyspike I'm not sure if ApplyFilters should return more detailed info, since it would expand it's scope from simply applying filters on a manifest, into generating addition info from a manifest. Thoughts ?

buddhike commented 6 years ago

It does not necessarily have to be in ApplyFilters. Could be a wrapper around it. But I guess we need a function that would return a set of filtered modules, their dependencies and dependents in expanded form. This would make it easier to implement operations like "grouped visualisation" right?

For example, what if the return type of ApplyFilters is something like:

type FilteredModules struct {
    Modules Modules
    Dependencies Modules // Expanded dependencies
    Dependants Modules // Expanded dependents
}

Just a thought, I'm sure something will flesh out once you get the fingers on the keyboard 😄 .

ojizero commented 6 years ago

Hmmm, wouldn't it be a little bit redundant having a structure to hold both modules, and their dependencies and dependents? That is, you can extract all the info in such structure directly from the Modules struct (so long as you're in lib package) so why duplicate this info. 😬

ojizero commented 6 years ago

@buddyspike I am wondering if the serializer should receive some form of options parameters (akin to the ApplyFilters for example) that could be used to define it's intended output, for example something of the likes of

type SerializeOpts struct {
    showDependents    bool
    showDependencies  bool
    mainColor         string
    dependentsColor   string
    dependenciesColor string
}

and based on the passed options the serializer emits the needed graph, this way we can isolate graph generation and all its needed information inside the serializer function (potentially through other methods that aren't exported).

ojizero commented 6 years ago

@buddyspike sorry for the delay on my end but I couldn't find much free time in the past weeks 😅, I opened #116 to discuss how I tried to go about changing the SerializeAsDot method.

buddhike commented 6 years ago

@ojizero, Don't apologise man 😄. Thanks again for the awesome contributions. Take it easy!