enhancement request

That could be a great enhancement to facilitate visualization on the graph.
Typically, I would like to visually separate on the graph utility classes from domain classes, but still group them by usage area rather than groups.

ps: thanks for that great tool

Hello,
This is a great tool. Nice work.
Noticed that in your composer.json you have quite strong version specs like symfony/console: 2.6.*. Haven't tried though, but think it won't work if my project is on other symfony version, 2.3, 2.5 or 2.7. Guess then I could not add your tool to my composer.json, but would have to have a separate installation for it, and that would complicate plugin maintenance. Could you consider loosening a bit on your dependencies and use ~ version spec so the tool can be added to app require-dev w/out dependency conflicts?

enhancement request
would allow to organize the graph in a more hierarchical way.
would expect the configuration to smoothly evolve to something like:
groupLength: 2,3

then in that case, there would be a first level group with level 2 namespaces, and within that group, a set of sub groups with level 3 subnamespaces.

My Environment (version of the project, operating system, or hardware)

...replace me...

My phpda.yml:

...replace me...

When I run this command:

...replace me...

Actual behavior:

...replace me...

Expected behavior:

...replace me...

My Environment (version of the project, operating system, or hardware)

• MacOS
• Ubuntu

PHP 7.4.8 (cli) (built: Jul  9 2020 23:43:51) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.8, Copyright (c), by Zend Technologies

When I run this command:

composer require --dev  mamuz/php-dependency-analysis

Actual behavior:

Using version ^2.0 for mamuz/php-dependency-analysis
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Conclusion: don't install mamuz/php-dependency-analysis v2.0.2
    - Conclusion: don't install roave/better-reflection 4.8.0
    - Conclusion: don't install phpdocumentor/reflection-docblock 4.3.4|install roave/better-reflection 4.8.0
    - Conclusion: don't install phpdocumentor/reflection-docblock 5.2.1
    - Conclusion: don't install roave/better-reflection 4.7.0
    - Conclusion: don't install phpdocumentor/reflection-docblock 4.3.2|install roave/better-reflection 4.7.0|install roave/better-reflection 4.8.0|install phpdocumentor/reflection-docblock 5.2.1
    - Conclusion: don't install phpdocumentor/reflection-docblock 4.3.3|install roave/better-reflection 4.7.0|install roave/better-reflection 4.8.0
    - Installation request for phpat/phpat ^0.7.3 -> satisfiable by phpat/phpat[0.7.3].
    - Conclusion: don't install phpdocumentor/reflection-docblock 5.2.0
    - mamuz/php-dependency-analysis v2.0.1 requires phpdocumentor/reflection-docblock ~4.0 -> satisfiable by phpdocumentor/reflection-docblock[4.0.0, 4.0.1, 4.1.0, 4.1.1, 4.2.0, 4.3.0, 4.3.1, 4.3.2, 4.3.3, 4.3.4].
    - mamuz/php-dependency-analysis v2.0.0 requires phpdocumentor/reflection-docblock ~4.0 -> satisfiable by phpdocumentor/reflection-docblock[4.0.0, 4.0.1, 4.1.0, 4.1.1, 4.2.0, 4.3.0, 4.3.1, 4.3.2, 4.3.3, 4.3.4].
    - Can only install one of: phpdocumentor/reflection-docblock[5.1.0, 4.0.0].
    - Can only install one of: phpdocumentor/reflection-docblock[5.1.0, 4.0.1].
    - Can only install one of: phpdocumentor/reflection-docblock[5.1.0, 4.1.0].
    - Can only install one of: phpdocumentor/reflection-docblock[5.1.0, 4.1.1].
    - Can only install one of: phpdocumentor/reflection-docblock[5.1.0, 4.2.0].
    - Can only install one of: phpdocumentor/reflection-docblock[5.1.0, 4.3.0].
    - Can only install one of: phpdocumentor/reflection-docblock[5.1.0, 4.3.1].
    - Conclusion: install roave/better-reflection 4.7.0|install roave/better-reflection 4.8.0|install phpdocumentor/reflection-docblock 5.1.0|install phpdocumentor/reflection-docblock 5.2.0|install phpdocumentor/reflection-docblock 5.2.1
    - Installation request for mamuz/php-dependency-analysis ^2.0 -> satisfiable by mamuz/php-dependency-analysis[v2.0.0, v2.0.1, v2.0.2].

Expected behavior: Package is installed.

Can you please check it out?
(composer require mamuz/php-dependency-analysis "0.6.1" works)

  Problem 1
    - phpdocumentor/reflection-docblock 3.0.0 requires phpdocumentor/reflection-common ^1.0@dev -> no matching package found.
    - mamuz/php-dependency-analysis v1.1.0 requires phpdocumentor/reflection-docblock ~3.0 -> satisfiable by phpdocumentor/reflection-docblock[3.0.0].
    - Installation request for mamuz/php-dependency-analysis ^1.1 -> satisfiable by mamuz/php-dependency-analysis[v1.1.0].

Hey Marco, thanks for a great tool! Really well done!

I have a situation of a project with many packages (grouped by folders) that mutually depend variously. The idea is to take one namespace and to find all other namespaces depend on it (let's name this specific namespace AnalysedFoo). If run the tool by folder it shows me only outgoing connection (or at least it doesn't show incoming dependencies that are located in other folders). If I run the tool for the entire project folder it takes way too long and the result will be probably anyway too complex and unacceptable. The excludePattern doesn't seem to work here as he can only filter out AnalysedFoo and leave all the rest (excludePattern: '/AnalysedFoo/'), or if I negate the pattern (excludePattern: '/^(?!.*AnalysedFoo).*$/') all incoming dependencies are dropped off.

To make it more clear:

• MyFolder
  • MySubFolderA (contains AnalysedFoo)
  • MySubFolderB (contains namespaces depend on AnalysedFoo and on namespaces in MySubFolderC)
  • MySubFolderC (contains namespaces depend on AnalysedFoo and on namespaces in MySubFolderD)
  • MySubFolderD (contains namespaces depend on something else)

So I want to see a diagram like

 +---------------------+
 |MyFolder\MySubFolderB|--+
 +---------------------+  |
                          |
 +---------------------+  |   +------------------------+
 |MyFolder\MySubFolderC|--+-->|MySubFolderA\AnalysedFoo|
 +---------------------+      +------------------------+

and nothing more.

Do you have any ideas how to approach a solution?

Thanks in advance!

My Environment

• Windows 10
• Tested with
  • PHP 7.3 => phpda v2.0.2
  • PHP 7.2 => phpda v1.3.1
• GraphViz 2.44: (https://ci.appveyor.com/project/ellson/graphviz-pl238/builds/32032002)
• Composer installation

My phpda.yml:

mode: 'usage'
source: 'src'
filePattern: '*.php'
ignore: 'tests'
formatter: 'PhpDA\Writer\Strategy\Svg'
target: './phpda.svg'
groupLength: 1
visitor:
  - PhpDA\Parser\Visitor\TagCollector
  - PhpDA\Parser\Visitor\SuperglobalCollector
visitorOptions:
  PhpDA\Parser\Visitor\Required\DeclaredNamespaceCollector: {minDepth: 2, sliceLength: 2}
  PhpDA\Parser\Visitor\Required\MetaNamespaceCollector: {minDepth: 2, sliceLength: 2}
  PhpDA\Parser\Visitor\Required\UsedNamespaceCollector: {minDepth: 2, sliceLength: 2}
  PhpDA\Parser\Visitor\TagCollector: {minDepth: 2, sliceLength: 2}

When I run this command:

.\vendor\bin\phpda.bat analyze phpda.yml

Actual behavior:

Error:

Write dependency graph to C:\xxx\./phpda.svg
Error: C:\xxx\AppData\Local\Temp\graE965.tmp: syntax error in line 3 near '-1'

Temp file:

digraph {
  graph [rankdir="LR" ranksep=1 nodesep=0.1 fontsize=8 label="PhpDependencyAnalysis by Marco Muths (dev-master)"]
  subgraph cluster_-1 {
...

It seems that graphviz does not accept group ids like subgraph cluster_-1:

When I remove the *-1 in https://github.com/mamuz/PhpDependencyAnalysis/blob/v2.0.2/src/Layout/Helper/GroupGenerator.php#L97 everything works fine.

Hey Marco!

It would be cool if phpda returned a proper code when it finds violations. If it returns 1 (or any nonzero) it could be used in the building process. The build would fail if any violation is found.

I think here you can find an exemple on how to manipulate the return code.

Cheers!

I have an old project that does not use namespace (only ) and a set of classes alias.
I'm trying to implement a namespace filter to mimic package (namespace) and class alias.
I discovered that the filter is never called. Here is a simplified scenario to reproduce the issue.

My Environment (version of the project, operating system, or hardware)

Debian 9
PhpDependencyAnalysis by Marco Muths v1.3.1
PHP 5.6.40-1+0~20190111135530.9+stretch~1.gbp5f42c9 (cli)
dot - graphviz version 2.38.0 (20140413.2041)

My phpda.yml:

mode: 'call'
source: './web'
filePattern: '*.php'
ignore: [ 'cache','test','install173','modules', 'Tests','fonts','tools', 'override' ]
formatter: 'PhpDA\Writer\Strategy\Svg'
target: './web/total0.svg'
namespaceFilter: PS\Plugin\CoreNamespaceFilter
groupLength: 2
visitor:
  - PhpDA\Parser\Visitor\TagCollector
  - PhpDA\Parser\Visitor\NamespacedStringCollector
  - PhpDA\Parser\Visitor\IocContainerAccessorCollector
visitorOptions:
  - PhpDA\Parser\Visitor\Required\DeclaredNamespaceCollector: {minDepth: 2, sliceLength: 2}
  - PhpDA\Parser\Visitor\Required\MetaNamespaceCollector: {minDepth: 2, sliceLength: 2}
  - PhpDA\Parser\Visitor\Required\UsedNamespaceCollector: {minDepth: 2, sliceLength: 2}
  - PhpDA\Parser\Visitor\TagCollector: {minDepth: 2, sliceLength: 2}
classMap:
  PS\Plugin\CoreNamespaceFilter: './CoreNamespaceFilter.php'

My filter

<?php

namespace PS\Plugin;

use PhpDA\Parser\Filter\NamespaceFilterInterface;

class CoreNamespaceFilter implements NamespaceFilterInterface
{

    public function filter(array $nameParts)
    {
        die(print_r($nameParts,1));
    }
}

When I run this command:

phpda analyze phpda.yml

Actual behavior:
svg is generated but filter never called
( Never die - Note that a die in the constructer works as expected - hence plugins is loaded )

Expected behavior:
filter to be called.

My Environment (version of the project, operating system, or hardware)

• PhpDependencyAnalysis by Marco Muths (v1.3.0)
• Debian Jessie

My phpda.yml:

Not important

When I run this command:

$ phpda analyze ./phpdaConfig.yml

Actual behavior:

I get this error:

[InvalidArgumentException]
Configfile "./phpdaConfig.yml" is not readable

Expected behavior:

It should work no matter whether I use a relative path or an absolute path.

Currently it works only if I use an absolute path like this one:

$ phpda analyze ~/www/testsite/php-lib/DavidCim/WebRender/docs/phpdaConfig.yml

Not needed to say that I am running the command from the right directory.

Please would you have a default config file name, like phpda.yaml so that it can be added to packages alongside things like phpunit.xml and the like?

That way the command can be run without specifying a config file and look for the local phpda.yaml file.

My Environment (version of the project, operating system, or hardware):
Any environment will do. I'm using phpda 2.0.2 from composer.

My phpda.yml:
Any config file, e.g. the default.

When I run this command: vendor/bin/phpda

If the project analyzed uses PSR5 array union types, e.g.

* @return (string|array)[]

You get:

Warning "\array)" is not a valid Fqsen. on line [line + file]

PSR5 array union types are already supported by TypeResolver/ReflectionDocBlock. The problem seems to be that, in order to parse the union type, TypeResolver splits the line at ( and )[] (ref).
However, NameResolver strips every occurrence of [], hence TypeResolver will try to split (string|array), which in turn gives the following parts:

[ '(', 'string', '|', 'array)' ]

and the last one isn't recognised as a valid type.

The process is repeatedly hanging on writing to the dependency graph file. This happens both with the SVG and DOT writers. Attached is a shortened php process sample (the original sample was over 600 MB).

I'm working with a large project, phpda puts it at 2520 files. The analysis itself usually takes about a minute and ends with about 90 MiB memory usage. Here's some typical output:

2520/2520 [============================] 100%  1 min/1 min  Memory: 91.5 MiB

phpda-sample-short.txt

Last part of README in this repo (named "Alternatives") links to Code Analysis Section at Awesome PHP. Anyway, this repo is listed in Static Analysis Section at Awesome PHP
Which one is right?

Hi there

For my project i need to use hhvm as it reduces the building of the model from ~30mins to ~3mins. Everything works fine most of the time. But if i a file gets parsed that starts with:

!/usr/bin/php

Hi @mamuz,

while using your project I encountered an annoying little issue: whenever I run an analysis in a single given format, but I wanted e.g. a JSON and a SVG result, I had to execute the analysis 2 times with 2 slightliy different configurations, meaning I had my builds to run half as fast as I wished I could.

As far as I see, a small modification wthin the AbstractStrategy (iterating over 2 new arrays) would overcome my issue. I could also imagine a fallback to accept strings as configuration in order to ensure BC.

What do you think about this enhancement? Would it add a benefit to your project? Or should I work around my issue on my side?

Best regards,
@cawolf

Environment:

• phpda 1.3.1
• php 7.2
• Linux

Actual:

Done

Logs:
Error	Syntax error, unexpected '?' on line 35 ./src/Contracts/Definition/Behaviour/ProvidesArguments.php
Error	Syntax error, unexpected '?' on line 35 ./src/Contracts/Definition/Behaviour/ProvidesFields.php
Error	Syntax error, unexpected '?' on line 36 ./src/Contracts/Definition/Behaviour/ProvidesInputFields.php
Error	Syntax error, unexpected '?' on line 34 ./src/Contracts/Definition/Behaviour/ProvidesInterfaces.php
Error	Syntax error, unexpected '?' on line 28 ./src/Contracts/Definition/Behaviour/ProvidesLocations.php
Error	Syntax error, unexpected '?' on line 25 ./src/Contracts/Definition/Behaviour/ProvidesSchema.php
Error	Syntax error, unexpected T_CONST, expecting T_FUNCTION on line 22 ./src/Contracts/Definition/Dependent/DirectiveLocation.php
Error	Syntax error, unexpected '?' on line 34 ./src/Contracts/Definition/EnumDefinition.php
Error	Syntax error, unexpected T_CONST, expecting T_FUNCTION on line 20 ./src/Contracts/Definition/SchemaDefinition.php
Error	Syntax error, unexpected '?' on line 34 ./src/Contracts/Invocation/Behaviour/ProvidesPassedArguments.php
Error	Syntax error, unexpected T_CONST, expecting T_FUNCTION on line 20 ./src/Contracts/Type.php

Files example:

    public function getArgumentDefinition(string $name): ?ArgumentDefinition; // Error on this line (return typehint)

Expected:

OK

First thanks for this lib, it's great! But would it be possible to have a PHAR file with a self-update command to use it? Installing the lib via Composer is not always possible, especially for this kind of library depending on specific version of phpdocumentor/reflection-docblock and nikic/php-parser.

My Environment (version of the project, operating system, or hardware)

vagrant + windows 10

My phpda.yml:

none

When I run this command:

composer require --dev mamuz/php-dependency-analysis

Actual behavior:

 composer require --dev mamuz/php-dependency-analysis
Using version ^1.3 for mamuz/php-dependency-analysis
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - mamuz/php-dependency-analysis v1.3.1 requires symfony/yaml ~2.5|~3.0 -> satisfiable by symfony/yaml[2.5.x-dev, 2.6.x-dev, 2.7

Expected behavior:

installed

Hi there,

will the package work with Doctrine collections 1.3.0 ?

My Environment:
Image Inspection

  "Created" : "2019-04-11T16:01:41.794400681Z",
  "DockerVersion" : "18.03.1-ee-3",
  "Id" : "sha256:93b4a875d42eaac95fbfcc1187922a70ffc4c657e47d9241c2e638a2b512c8b8",
  "Os" : "linux",
  "OsVersion" : null,
  "Parent" : "",
  "Size" : 109392129,
  "RepoTags" : [ "mamuz/phpda:latest" ],

My phpda.yml:
Basically from the README.md

mode: 'usage'
source: './api'
filePattern: '*.php'
ignore: 'tests'
formatter: 'PhpDA\Writer\Strategy\Svg'
target: './phpda.svg'
groupLength: 1
visitor:
  - PhpDA\Parser\Visitor\TagCollector
  - PhpDA\Parser\Visitor\SuperglobalCollector
visitorOptions:
  PhpDA\Parser\Visitor\Required\DeclaredNamespaceCollector: {minDepth: 2, sliceLength: 2}
  PhpDA\Parser\Visitor\Required\MetaNamespaceCollector: {minDepth: 2, sliceLength: 2}
  PhpDA\Parser\Visitor\Required\UsedNamespaceCollector: {minDepth: 2, sliceLength: 2}
  PhpDA\Parser\Visitor\TagCollector: {minDepth: 2, sliceLength: 2}

When I run this command:

docker run --rm -v "%cd%":/app mamuz/phpda

Actual behavior:
Output of following, with the cursor blinking at the end. Remains on that state still after an hour.

PhpDependencyAnalysis by Marco Muths v2.0.2

Configuration read from /app/phpda.yml

   0/2293 [>---------------------------]   0% < 1 sec/< 1 sec Memory: 26.0 MiB
 229/2293 [==>-------------------------]   9% 2 secs/20 secs Memory: 32.0 MiB
 458/2293 [=====>----------------------]  19% 3 secs/15 secs Memory: 34.0 MiB
 687/2293 [========>-------------------]  29% 5 secs/17 secs Memory: 36.0 MiB
 916/2293 [===========>----------------]  39% 6 secs/15 secs Memory: 36.0 MiB
1145/2293 [=============>--------------]  49% 8 secs/16 secs Memory: 44.0 MiB
1374/2293 [================>-----------]  59% 10 secs/17 secs Memory: 46.0 MiB
1603/2293 [===================>--------]  69% 12 secs/17 secs Memory: 46.0 MiB
1832/2293 [======================>-----]  79% 14 secs/18 secs Memory: 46.0 MiB
2061/2293 [=========================>--]  89% 17 secs/19 secs Memory: 46.0 MiB
2290/2293 [===========================>]  99% 19 secs/19 secs Memory: 48.0 MiB
2293/2293 [============================] 100% 19 secs/19 secs Memory: 48.0 MiB

Write dependency graph to /app/./phpda.svg

Expected behavior:
svg should be generated and the console should report its progress and finally a success or detailed error message.

Hi, I see that this library can only accept directories as the source. I can see that this makes sense.
What do you think of also accept single files?
Sometimes I have files with such an amount of dependencies that I'm only to understand its dependencies individually.

Another way of solving it: Could we possible generate multiple svgs in such situations?
I mean, could we optionally generate a svg(target) for each file?

I know this may sound odd, but what do you think of it?

Hi. I'm trying to analyze usage for single class on whole project.

It's possible to create such configuration?

I'm getting this warning on an analyzer-run:

Warning	"\Some\Namespace\Here\https://www.hipchat.com/docs/apiv2/method/get_room" is 
not a valid Fqsen. on line 75 ./src/some/namespace/here/Class.php

From the referenced api-doc:

/**
 * @see https://www.hipchat.com/docs/apiv2/method/get_room
 */

Looking at https://www.phpdoc.org/docs/latest/references/phpdoc/tags/see.html, the @see tag can either take a FQSEN, or an URI, which is wrongly interpreted here.

Hey, thank you for the great project! I am trying to invoke PhpDA from within another console application and thus not directly using the CLI scripts the project provides. What I would like to do now is to define a more sophisticated ReferenceValidator that requires some configuration at runtime.

Currently, the ReferenceValidator does not support constructor-injection, as the validator is simply instantiated by the plugin loader (which is totally fine for the CLI usage). Also, it is not possible to somehow get the instantiated ReferenceValidator by the API and therefore it is also not possible to use setter-injection.

A simple way to enable either-or is to change the current config implementation as follows:

public function getReferenceValidator()
{
    if (!is_null($this->referenceValidator) && !is_string($this->referenceValidator) && !($this->referenceValidator instanceof ValidatorInterface)) {
        throw new \InvalidArgumentException('Config for referenceValidator must be an string');
    }
    return $this->referenceValidator;
}

The plugin loader would then need to check whether there is already an object coming from the config and then skip instantiation. I guess the proposed approach seems a bit like a workaround, but it should work at least :-).

What do you think? If the proposed approach is fine for you I'd be happy to help with the implementation!

sometimes developer want to analyze some parts of the code, can source in config be array? If not, I think maybe I can add this feature.

root@homestead:~/Projects# phpda analyze proff.yml
PhpDependencyAnalysis by Marco Muths (v1.2.0)

I catched next trouble when I try to run this tools on my homestead machine.

Configuration read from /home/vagrant/Projects/proff.yml

32/32 [============================] 100% 1 sec/1 sec Memory: 14.0 MiB

Write dependency graph to /home/vagrant/Projects/graf.svg
sh: 1: dot: not found

[Fhaculty\Graph\Exception\UnexpectedValueException]
Unable to invoke "dot" to create image file (code 127)

analyze [-m|--mode [MODE]] [-s|--source [SOURCE]] [-p|--filePattern [FILEPATTERN]] [-i|--ignore [IGNORE]] [-f|--formatter [FORMATTER]] [-t|--target [TARGET]] [--] []

Custom filter plugin, implementing NamespaceFilterInterface interface, declared in yml as namespaceFilter option and added to composer autoload.
The plugin class is well loaded, but the filter method is never called.

Even after removing composer.lock, after running composer require --dev mamuz/php-dependency-analysis, following error happens:

Cannot use mamuz/php-dependency-analysis's latest version v2.0.2 as it requires php ^7.3 which is not satisfied by your platform.
./composer.json has been updated
Running composer update mamuz/php-dependency-analysis
Loading composer repositories with package information
Updating dependencies                                 
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - mamuz/php-dependency-analysis[v0.0.1, ..., v0.1.3] require symfony/console 2.5.* -> found symfony/console[v2.5.0, ..., v2.5.12] but it conflicts with your root composer.json require (^6.2).
    - mamuz/php-dependency-analysis[v0.2.0, ..., v0.5.0] require symfony/console 2.6.* -> found symfony/console[v2.6.0, ..., v2.6.13] but it conflicts with your root composer.json require (^6.2).
    - mamuz/php-dependency-analysis[v0.5.1, ..., v0.6.0] require symfony/console ~2.5 -> found symfony/console[v2.5.0, ..., v2.8.52] but it conflicts with your root composer.json require (^6.2).
    - mamuz/php-dependency-analysis[v0.6.1, v1.0.0, ..., v1.2.0] require symfony/console ~2.5|~3.0 -> found symfony/console[v2.5.0, ..., v2.8.52, v3.0.0, ..., v3.4.47] but it conflicts with your root composer.json require (^6.2).
    - mamuz/php-dependency-analysis[v1.3.0, ..., v1.3.1] require php ^5.6 || ^7.0 -> your php version (8.1.11) does not satisfy that requirement.
    - mamuz/php-dependency-analysis[v2.0.0, ..., v2.0.2] require php ^7.3 -> your php version (8.1.11) does not satisfy that requirement.
    - Root composer.json requires mamuz/php-dependency-analysis * -> satisfiable by mamuz/php-dependency-analysis[v0.0.1, ..., v0.6.1, v1.0.0, ..., v1.3.1, v2.0.0, v2.0.1, v2.0.2].

Hi, I have introduced a bug in your library.
When you call the analyze command in verbose mode, e.g. "bin/phpda analyze phpda.yml.dist -v"
The following exception is throw

  [InvalidArgumentException]              
  Invalid configuration setting: verbose 

This happens because we are passing all the input to the Config class.
Before trying to fix it I wanted to know what do you think.