search

JBZoo / Composer-Graph

Dependency graph visualization for composer.json (PHP + Composer) based on mermaid-js
MIT License
65 stars 7 forks source link

Feature Request: Add filter glob option #8

Open Anticom opened 2 years ago

Anticom commented 2 years ago

Rationale

In our project we have a lot of internal packages, but overall there's only a hand full of vendor prefixes to all those internal packages. I'm currently in search for a tool that allows me to render a visual dependency graph but with the ability to somehow specify what packages I want to be included in the final svg etc.

CLI API

It would be nice, if we had a flag to specify what packages we want to be included in our svg, such as --scope=myvendor/* where we could specify a pattern using common glob syntax that all packages are matched against to decide whether they should show up in the image or not.
In order to make this a non breaking change my suggestion would be to give that flag a default value of *, meaning that without overriding it we would still get all packages from all vendors displayed.

Implementation

My suggestion would be to use a library such as webmozart/glob and add a filtering stage after the dependency collection phase but before rendering (see discussion below).

Examples

php ./vendor/bin/composer-graph

Would use the default value for --scope flag of *, meaning all packages are shown

php ./vendor/bin/composer-graph --scope=myvendor/*

Would only display dependencies where the vendor is myvendor.

php ./vendor/bin/composer-graph --scope=*abc*

Would only display dependencies where abc is either part of the vendor name or the package name.

php ./vendor/bin/composer-graph --scope={foo,bar}/*

Would only display dependencies where the vendor is either foo or bar.

Discussion

One major issue with this approach is that we might end up with multiple disconnected DAGs, for example with a dependency layout such as:

my/root
 +- vendor1/package1
 +- vendor2/package1
    +- vendor1/package2

When we supply --scope=vendor1/* then vendor2/package1 should be filtered out, however its dependency on vendor1/package2 should be included. There are probably multiple ways to tackle this issue:

  1. The most optimistic approach would probably to just leave it as multiple disconnected DAGs instead of ending up with a single one.
  2. When there's a transitive dependency that matches the scope with dependencies in between that don't match it, collapse those intermedia dependencies into a placeholder "hidden" etc.
  3. Prune the DAG as soon as we come across a dependency that doesn't match the specified scope. (In that case we would only end up with a single graph but "loose" transitive dependencies that do match the scope downstream.) Hence IMHO it's not a viable strategy.
SmetDenis commented 2 years ago

Hey,

I really like your idea. It looks pretty interesting and useful. I think I can implement it next major release, like next month or so.