mihaeu/dephpend

Detect flaws in your architecture, before they drag you down into the depths of dependency hell ...

dephpend's Issues

Compability with Symfony 4

Currently this package is incompatible with Symfony 4, due to composer.json:

        "symfony/console": "^2.0 || ^3.0",
        "symfony/event-dispatcher": "^2.0 || ^3.0"

SSL_ERROR_BAD_CERT_DOMAIN when trying to download phar.

I can't download phar from https://phar.dephpend.com/dephpend.phar receiving SSL error.

Track variables defined in the current scope

...

UML generation

The results of the prototype showed that Graphviz output, without putting lots of effort into styling, is useless.

PlantUML uses Graphviz for node positioning, but takes care of styling and already provides UML class diagram elements.

@startuml
Class01 <|-- Class02
Class03 *-- Class04
Class05 o-- Class06
Class07 .. Class08
Class09 -- Class10
@enduml

A prototype of php-dependencies generated the following output:

For the alpha version:

• composition and <<call>> dependencies should be added to the graph.
• the tool should check if PlantUML is available and either be shipped with PlantUML packaged or offer to download it and check for Java support

dot command cannot handle relative paths

Increase default size for PlantUML diagrams

See http://plantuml.com/faq

Set namespaces for legacy apps

Legacy apps are not using namespaces but instead use pseudo namespaced classes like My_Company_Package_Subpackage_Class.

For the generation of package scoped output (not outputting every single class) the user should be able to specify a namespace delimiter e.g. --namespace-delimiter="_"

Optionally mark visibility of a dependency in output

It would be useful to me to be able to distinguish between dependencies of different visibility, in particular "public" dependencies (subclassing, implemented interfaces, public method signatures) and "private" dependencies (private method signatures, use in method bodies). For a large and messy code base like MediaWiki, this would allow further analysis to distinguish between that are hard to fix (public dependencies) and things that are easy to fix (private dependencies).

This is a feature I so far have not seen in any static analysis tool. I'm wondering why, I can't be the only one who'd find this useful. Perhaps it's because static analysis tools are mostly used by design purists, and options to filter out some kinds of issues as "less bad" does not appeal to them?... When working with clean code, this kind of thing isn't needed. When trying to clean up an organically grown tangle of half a million lines, it would be great to have...

Anyway. In addition to "private" and "public", there are a few in-between visibilities to be consider:

• "constructor" (use in the constructor signature). Technically public, but constructor calls may be restricted to wiring code by convention, making it "internal" in a sense. For this to me useful, constructor usage should not be considered "public".
• "protected" - may have to be treated as private or public, depending on context.
• "internal" if the class or method has the @internal tag
• "deprecated" if the class or method has the @deprecated tag. This essentially makes this an extension of or alternative to issue #42.

In "text" output, with --visibility enabled, this flags could form a third column, perhaps using the form
Foo --> Bar @Private
FooBar --> Foo @public
FooBar --> Frob @Protected @deprecated

In GML (as proposed in #41) this could trivially be represented as additional attributes on the edges.

Dependency detection for explicit dependencies

The following types of *explicit dependencies (i.e. no dynamic new $$$$var();) should be detected:

• <<create>> dependencies (i.e. new X())
• <<call>> dependencies to globals and static dependencies
• <<call>> dependencies to injected dependencies (either through constructor or method injection)

Questions:

• are superglobals like $_POST relevant ($_GLOBALS is, but will not be supported in the alpha version)?

Composer global

Hi,

we have already dephpend in bin-Folder. Can you update your composer.json, that after "composer global require" we have dephpend ready for global usage. (https://getcomposer.org/doc/articles/vendor-binaries.md) Sorry for my english.

Incompatible with symfony/event-dispatcher 4.3

The composer.json file says "symfony/event-dispatcher": "^2.0 || ^3.0 || ^4.0", but the way the Dispatcher is implemented is apparently incompatible with versions 4.3 and later. It seems like no action is performed at all, since the dispatch() method never gets called. With symfony/event-dispatcher 4.2.10, things still work as expected.

DSM not counting correctly

The DSM right now counts how many dependencies one package has to another package (using --only-namespaces). By definition, this can only amount to one. The actual important information for the package level is how many classes of another package a package is depending on.

Write errors to stderr not stdout

Warnings should not pollute useful output.

Division by zero when result is empty

Warning: Division by zero in .../src/Analyser/Metrics.php on line 30

Syntax error message does not include filename

The error message shown below is missing information about the source code file it refers to:

Sorry, we could not analyse your dependencies, because the sources contain syntax errors:

Syntax error, unexpected T_STRING on line 1

Release Artifact: Can't check signature: No public key

I actually like to verify gpg keys. But looks like you did not provide a public key...

gpg --verify dephpend-0.6.0.phar.asc 
gpg: assuming signed data in 'dephpend-0.6.0.phar'
gpg: Signature made Do 11 Apr 2019 17:48:01 CEST
gpg:                using RSA key 22BD58D0E3B969122E5E1CF22BCCDC2E41A6C1AF
gpg:                issuer "[email protected]"
gpg: Can't check signature: No public key

Support for DI containers

Start with:

• Pimple
• Symfony\DependencyInjection (allows Yaml and XML configuration 😞)
• Laravel (probably the toughest)

Show global namespace in --no-classes

Show global namespace in --no-classes

Architecture DSL

Quick draft:

<?php

beforeClass() {
	// setup
	$fileSet = $finder->find(__DIR__ . '/src')
		->addAll($finder->find(__DIR__ . '/vendor'));
	$dependencies = $staticAnalyser->analyse($fileSet);

	// setup shorthand
	analyse('path1', 'path2');
}

// test
test() {
	$models = defineLayer()
		->from('Some\Namespace\Bla')
		->from('/special.*regex/');

	$views = defineComponent()
		->from('')
		->from('');

	$controllers
		->dependsOn($models)
		->but()
		->mayNotDependOn($views);

	$util
		->mayNotHaveDependencies();

	$views
		->mayNotBeDependentOn();

	package('Vendor/Namespace')
		->mayNotDependOn()
		->classesFromDir(__DIR__ . '/../vendor');

	classesMatching('/.*Service.*/')
		->mayOnlyDependOn()
		->classesMatching('/.*Provider.*/');
}

Assertions using xUnit i.e. PHPUnit Framework Assertions.

phar generation

Add phar generation to the build process to simplify distribution and testing.

Website down?

Getting a 404 from Github when trying to access https://dephpend.com.
According to https://www.githubstatus.com, Github pages should be up.

Thanks for the tool btw.

Update to Symfony 5.

This will be nice if this package is compatible with Symfony version 5.0.

This only a matter of update the composer.json file:

"require": {   
    "symfony/console": "^2.0 || ^3.0 || 4.0.* || 4.1.* || 4.2.* || 5.0.*",
    "symfony/event-dispatcher": "^2.0 || ^3.0 || ^4.0 || 5.0.*"
},

Improve --underscore-namespaces to fix invalid class names (^number)

--underscore-namespaces option is very usefull for projects that don't use namespaces to allow component/package level view. Unfortunataly in such project we can have classes like My_Class_2You . When "namespaced", it will result into invalid classname because it starts with number: My/Class/2You

It causes Fatal error even when I'm not interested in classes (--no-classes used).

It would be nice to come with solution for this issue.

Suggestions:

1. Autofix class names in mapNamespaces() method always
2. Fix classes when specified e.g. with --underscore-namespaces-fix
3. Or more specific - prefixing bad class names --underscore-namespaces-classfix-prefix (that would help to classes that start with number)
4. Or some kind of regular expression modification --underscrore-namespaces-fix-regex of invalid classes?

.. or maybe you have a better idea how to fix such issue ;)

There might be another invalid class name situation, but this one with the number at the beginning is the one which currently hinders me from using dephpend on the project I'm dealing with (without being forced to refactor such code).

Uncaught TypeError: Argument 1 passed to Mihaeu\PhpDependencies\Dependencies\DependencyFactory::createClazzFromStringArray() must be of the type array, null given

$ git clone [email protected]:mihaeu/dephpend.git

$ cd dephpend

$ composer update

$ cd ...

$ git clone [email protected]:symfony/symfony.git

$ cd symfony

$ composer update

$ ../dephpend/bin/dephpend text .
PHP Notice:  Undefined property: PhpParser\Node\Stmt\Class_::$namespacedName in /usr/local/src/dephpend/src/Analyser/DependencyInspectionVisitor.php on line 188
PHP Notice:  Trying to get property of non-object in /usr/local/src/dephpend/src/Analyser/DependencyInspectionVisitor.php on line 188
PHP Fatal error:  Uncaught TypeError: Argument 1 passed to Mihaeu\PhpDependencies\Dependencies\DependencyFactory::createClazzFromStringArray() must be of the type array, null given, called in /usr/local/src/dephpend/src/Analyser/DependencyInspectionVisitor.php on line 188 and defined in /usr/local/src/dephpend/src/Dependencies/DependencyFactory.php:14
Stack trace:
#0 /usr/local/src/dephpend/src/Analyser/DependencyInspectionVisitor.php(188): Mihaeu\PhpDependencies\Dependencies\DependencyFactory->createClazzFromStringArray(NULL)
#1 /usr/local/src/dephpend/src/Analyser/DependencyInspectionVisitor.php(59): Mihaeu\PhpDependencies\Analyser\DependencyInspectionVisitor->setCurrentClass(Object(PhpParser\Node\Stmt\Class_))
#2 /usr/local/src/dephpend/vendor/nikic/php-parser/lib/PhpParser/NodeTraverser.php(92): Mihaeu\PhpDependencies\Analyser\DependencyInspectionVisitor->enterNode(Object(PhpParser\Node\Stmt\Class_))
#3 /usr/local/src/dephpend/vendor/nikic/php-parser/lib/PhpParser/NodeTraverser.php(101): PhpParser\NodeTraverser->traverseNo in /usr/local/src/dephpend/src/Dependencies/DependencyFactory.php on line 14

Format DSM

The current table formatting makes the DSM utterly useless, because it's impossible to see anything.

• make the <th> align the text vertically
• highlight clicked cells

Wrong argument on ensureDestinationIsWritable()

On version 0.6.1, tried to run bin/dephpend dot myprojectpath and got

Argument 1 passed to Mihaeu\PhpDependencies\Cli\BaseCommand::ensureDestinationIsWritable() must be of the type string, null given, called in /mydir/dephpend/src/Cli/DotCommand.php on line 51
[/mydir/dephpend/src/Cli/BaseCommand.php at line 138]

Support GML output

While the plain text output of dependencies is nice for processing with grep, it would be nice to have an output format that can be used directly with more powerful graph analysis frameworks, such as graph-tool. GML seems to be a good candidate, since it's human readable and easy to generate.

Support plantuml.jar

Support plantuml.jar for those who can't or don't want to install it on their system.

Error running text mode

I'm running this command

docker run --rm -v <abs_path>:/inspect mihaeu/dephpend:latest text /inspect

and I'm getting this output

`Something went wrong, this shouldn't happen. Please take a minute and report this issue: https://github.com/mihaeu/dephpend/issues

Argument 1 passed to Mihaeu\PhpDependencies\Analyser\DependencyInspectionVisitor::addName() must be an instance of PhpParser\Node\Name, instance of PhpParser\Node\Expr\PropertyFetch given, called in /dephpend/src/Analyser/DependencyInspectionVisitor.php on line 89

[/dephpend/src/Analyser/DependencyInspectionVisitor.php at line 97]`

Website and phar disappeared

dephpend.com shows an apache default page.

https://phar.dephpend.com/dephpend.phar returns 404.

Error in text mode

Similar to #56

Using: docker, composer: 0.6.2, composer: dev-master

Argument 1 passed to Mihaeu\PhpDependencies\Analyser\DependencyInspectionVisitor::addName() must be an instance of PhpParser\Node\Name, instance of PhpParser\Node\Expr\ArrayDimFetch given, called in /root/.composer/vendor/dephpend/dephpend/src/Analyser/DependencyInspectionVisitor.php on line 90

AOP for dynamic analysis?

Hi,

I saw you're into dynamic analysis which I find really interesting. Have you ever considered using an AOP library plus Reflection to obtain param and return types?

To be honest, it's just a naive idea. I can't even say if it's better or worse than xdebug performance-wise.

Throw RuntimeException for --help option

Inside my container:

php /project/tools/dephpend --help
PHP Fatal error:  Uncaught Symfony\Component\Console\Exception\RuntimeException: Not enough arguments (missing: "source"). in phar:///root/.phive/phars/dephpend-0.3.0.phar/vendor/symfony/console/Input/Input.php:83
Stack trace:
#0 phar:///root/.phive/phars/dephpend-0.3.0.phar/vendor/symfony/console/Input/Input.php(49): Symfony\Component\Console\Input\Input->validate()
#1 phar:///root/.phive/phars/dephpend-0.3.0.phar/vendor/symfony/console/Input/ArgvInput.php(63): Symfony\Component\Console\Input\Input->__construct(Object(Symfony\Component\Console\Input\InputDefinition))
#2 phar:///root/.phive/phars/dephpend-0.3.0.phar/src/Cli/Application.php(144): Symfony\Component\Console\Input\ArgvInput->__construct(Array, Object(Symfony\Component\Console\Input\InputDefinition))
#3 phar:///root/.phive/phars/dephpend-0.3.0.phar/src/Cli/Application.php(41): Mihaeu\PhpDependencies\Cli\Application->createFakeInput()
#4 phar:///root/.phive/phars/dephpend-0.3.0.phar/bin/dephpend(33): Mihaeu\PhpDependencies\Cli\Application->__construct('      _       in phar:///root/.phive/phars/dephpend-0.3.0.phar/vendor/symfony/console/Input/Input.php on line 83

In my opinion it's not quite right to throw the exception here and does not look professional. Maybe replace it by message "Command/Option/Argument not found"?

Unable to execute this tool

Hello.

I have installed this tool via phive. Even if it installed dephpend v0.7.0, dephpend --version reports version 0.6.3, which feels a bit odd (maybe that phar is messed up?)

When I try to execute this library on a Symfony 5.1 project with PHP 7.4 (which is pretty big), I keep getting the following error:

$ dephpend text src
PHP Warning:  Undefined array key 314 in phar:///usr/local/bin/dephpend/vendor/nikic/php-parser/lib/PhpParser/Lexer.php on line 293
Something went wrong, this shouldn't happen. Please take a minute and report this issue: https://github.com/mihaeu/dephpend/issues

PhpParser\Lexer::getNextToken(): Return value must be of type int, null returned

[phar:///usr/local/bin/dephpend/vendor/nikic/php-parser/lib/PhpParser/Lexer.php at line 333]

Applying -vvv flag does not affect the output at all.

jdepend metrics

This feature depends on how many dependencies were detected. The math however does not change, so including this as a core feature for the alpha release makes sense.

• Number of Classes and Interfaces
• Afferent Couplings (Ca)
• Efferent Couplings (Ce)
• Abstractness (A)
• Instability (I)
• Distance from the Main Sequence (D)
• Package Dependency Cycles

Reference: jdepend documentation

It cannot parse this php 8 code.

final class SomeAction implements ActionInterface
{
    public function __construct(
        private SomeService $domain,
        private Request $request,
    ) {}
}

PHAR missing for new releases

phive install dephpend installs version 0.4.0, not 0.6.0. Not surprising, though, as the releases are missing on https://phar.dephpend.com/.

Mihaeu\PhpDependencies\Util\DI is missing

But referenced in src/Cli/TestFeaturesCommand.php

Maybe related to #7

Make --output optional

All commands, including those producing binary output (e.g. .png) can output to stdout directly. This would allow for one line calls like

bin/dephpend uml src | display

instead of having to write it to an intermediate file.

Replace Symfony console

Symfony's console component makes proper dependency (constructor) injection very difficult:

• a Command's arguments and options are coupled to the Command
• verifying and accessing input requires the InputDefinition of a Command
• therefore injecting dependencies into a Command is not possible if the dependencies require information from the Input

Right now there's an ugly hack which pre-creates the requested Command and then discards it after parsing the Input.

This in addition to the difficulties and extra effort required in testing the Commands makes an custom implementation worthwhile.

Handle PhpParser errors more gracefully

When PhpParser encounters malformed code, the whole app crashes without explaining why:

#13

Allow filtering out dependencies introduced by deprecated methods and classes.

When refactoring a code base that needs to maintain a stable interface, it's often necessary to keep undesirable dependencies in deprecated methods until some later release. It would be useful to be able to see what the dependencies would look like with all the deprecated stuff removed. The respective filter would skip all classes and methods with the @deprecated tag in the documentation.

Same closure arg order for functional collections (set, map, tree, ...)

Closures for functional access methods like map or reduce should have the same signature for different implementations. Also $value, $key doesn't make sense and is confusing. Use index for key for sets and leaf identifier for trees.

Don't treat class name literals as dependencies

Class name literals, like FooBar::class, should not be treated as a dependency on the class FooBar. Such literals are really just syntactic sugar for string literals like "FooBar", they don't require the class to be loaded, or even to exist at all.

Technically, class name literals are a dependency on the class name, as they have to be updated when the class is renamed. If this kind of dependency should still be tracked, the mechanism for marking the dependency type suggested in #43 could be used to mark such dependencies as "name".

Add phar to phive

• get SSL certificate for server
• generate phar page using Sebastian's generator
• sign the phar
• fork and add the phive repo info

Wrong description for "text" command

$ ./bin/dephpend text --help
Description:
  Generate a Dependency Structure Matrix of your dependencies

Syntax error

Running ./dephpend.phar metrics gives me a syntax error:

[PhpParser\Error]
Syntax error, unexpected T_ELLIPSIS, expecting T_STRING or T_VARIABLE or '{' or '$' on line 145

(dePHPend Phar Sept 15th, 12:30). Other commands seem to have the same problem.

Docker container rebuild

There is an issue with docker container.
Image needs to be rebuild one in docker hub is no the one in Dockerfile. Automated build would be great also in docker hub there is no link back to github or builded Dockerfile, this looks kind a bad.

Also would be great if entry point has raised php memory limit. Or in readme could be example how to raise memory limit with docker by overriding entry point.

 docker run -it -v $PWD/src:/inspect --entrypoint "/usr/local/bin/php" mihaeu/dephpend:latest -n -d memory_limit=-1 /usr/src/dephpend/bin/dephpend text /inspect

dephpend --version throws error

dephpend.phar, version 0.5.0

# dephpend.phar --version
PHP Fatal error:  Uncaught Symfony\Component\Console\Exception\RuntimeException: Not enough arguments (missing: "source"). in phar:///usr/local/bin/dephpend.phar/vendor/symfony/console/Input/Input.php:76
Stack trace:
#0 phar:///usr/local/bin/dephpend.phar/vendor/symfony/console/Input/Input.php(42): Symfony\Component\Console\Input\Input->validate()
#1 phar:///usr/local/bin/dephpend.phar/vendor/symfony/console/Input/ArgvInput.php(61): Symfony\Component\Console\Input\Input->__construct(Object(Symfony\Component\Console\Input\InputDefinition))
#2 phar:///usr/local/bin/dephpend.phar/src/Cli/Application.php(150): Symfony\Component\Console\Input\ArgvInput->__construct(Array, Object(Symfony\Component\Console\Input\InputDefinition))
#3 phar:///usr/local/bin/dephpend.phar/src/Cli/Application.php(41): Mihaeu\PhpDependencies\Cli\Application->createFakeInput()
#4 phar:///usr/local/bin/dephpend.phar/bin/dephpend(33): Mihaeu\PhpDependencies\Cli\Application->__construct('      _      __...', '0.5.0', Object(Mihaeu\PhpDependencies\DI\DI))
#5 /u in phar:///usr/local/bin/dephpend.phar/vendor/symfony/console/Input/Input.php on line 76

When reporting syntax errors, mention the file name

Currently, when a syntax error is found in the code base, the error report looks like this:

  Sorry, we could not analyse your dependencies, because the sources contain syntax errors:
  Syntax error, unexpected T_SL on line 1235

There is no indication what file the error is in, which is problematic in a large code base. This is especially annoying if the error can't easily be found with other tools, because it's not a "real" syntax error, but rather an incompatibility with an obscure language feature or syntax introduced by a new version of php.

Somewhere on the stack that reports the error, information exists about which file was currently being processed. It would be helpful to include that information in the output.