Feature Request: Add filter glob option
Anticom opened this issue · comments
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:
- The most optimistic approach would probably to just leave it as multiple disconnected DAGs instead of ending up with a single one.
- 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.
- 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.
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.