shipmonk / composer-dependency-analyser
Fast detection of composer dependency issues (dead dependencies, shadow dependencies, misplaced dependencies)
Installs: 747 913
Dependents: 118
Suggesters: 0
Security: 0
Stars: 399
Watchers: 4
Forks: 10
Open Issues: 3
Requires
- php: ^7.2 || ^8.0
- ext-json: *
- ext-tokenizer: *
Requires (Dev)
- ext-dom: *
- ext-libxml: *
- editorconfig-checker/editorconfig-checker: ^10.3.0
- ergebnis/composer-normalize: ^2.19
- phpcompatibility/php-compatibility: ^9.3
- phpstan/phpstan: ^1.10.63
- phpstan/phpstan-phpunit: ^1.1.1
- phpstan/phpstan-strict-rules: ^1.2.3
- phpunit/phpunit: ^8.5.28 || ^9.5.20
- shipmonk/name-collision-detector: ^2.0.0
- slevomat/coding-standard: ^8.0.1
This package is auto-updated.
Last update: 2024-10-04 11:45:20 UTC
README
- πͺ Powerful: Detects unused, shadow and misplaced composer dependencies
- β‘ Performant: Scans 15 000 files in 2s!
- βοΈ Configurable: Fine-grained ignores via PHP config
- πΈοΈ Lightweight: No composer dependencies
- π° Easy-to-use: No config needed for first try
- β¨ Compatible: PHP 7.2 - 8.4
Comparison:
*Time measured on codebase with ~15 000 files
Installation:
composer require --dev shipmonk/composer-dependency-analyser
Note that this package itself has zero composer dependencies.
Usage:
vendor/bin/composer-dependency-analyser
Example output:
Found shadow dependencies! (those are used, but not listed as dependency in composer.json) β’ nette/utils e.g. Nette\Utils\Strings in app/Controller/ProductController.php:24 (+ 6 more) Found unused dependencies! (those are listed in composer.json, but no usage was found in scanned paths) β’ nette/utils (scanned 13970 files in 2.297 s)
Detected issues:
This tool reads your composer.json
and scans all paths listed in autoload
& autoload-dev
sections while analysing:
Shadowed dependencies
- Those are dependencies of your dependencies, which are not listed in
composer.json
- Your code can break when your direct dependency gets updated to newer version which does not require that shadowed dependency anymore
- You should list all those packages within your dependencies
Unused dependencies
- Any non-dev dependency is expected to have at least single usage within the scanned paths
- To avoid false positives here, you might need to adjust scanned paths or ignore some packages by
--config
Dev dependencies in production code
- For libraries, this is risky as your users might not have those installed
- For applications, it can break once you run it with
composer install --no-dev
- You should move those from
require-dev
torequire
Prod dependencies used only in dev paths
- For libraries, this miscategorization can lead to uselessly required dependencies for your users
- You should move those from
require
torequire-dev
Unknown classes
- Any class that cannot be autoloaded gets reported as we cannot say if that one is shadowed or not
Unknown functions
- Any function that is used, but not defined during runtime gets reported as we cannot say if that one is shadowed or not
Cli options:
--composer-json path/to/composer.json
for custom path to composer.json--dump-usages symfony/console
to show usages of certain package(s),*
placeholder is supported--config path/to/config.php
for custom path to config file--version
display version--help
display usage & cli options--verbose
to see more example classes & usages--show-all-usages
to see all usages--format
to use different output format, available are:console
(default),junit
--ignore-unknown-classes
to globally ignore unknown classes--ignore-unknown-functions
to globally ignore unknown functions--ignore-shadow-deps
to globally ignore shadow dependencies--ignore-unused-deps
to globally ignore unused dependencies--ignore-dev-in-prod-deps
to globally ignore dev dependencies in prod code--ignore-prod-only-in-dev-deps
to globally ignore prod dependencies used only in dev paths
Configuration:
When a file named composer-dependency-analyser.php
is located in cwd, it gets loaded automatically.
The file must return ShipMonk\ComposerDependencyAnalyser\Config\Configuration
object.
You can use custom path and filename via --config
cli option.
Here is example of what you can do:
<?php use ShipMonk\ComposerDependencyAnalyser\Config\Configuration; use ShipMonk\ComposerDependencyAnalyser\Config\ErrorType; $config = new Configuration(); return $config //// Adjusting scanned paths ->addPathToScan(__DIR__ . '/build', isDev: false) ->addPathToExclude(__DIR__ . '/samples') ->disableComposerAutoloadPathScan() // disable automatic scan of autoload & autoload-dev paths from composer.json ->setFileExtensions(['php']) // applies only to directory scanning, not directly listed files //// Ignoring errors ->ignoreErrors([ErrorType::DEV_DEPENDENCY_IN_PROD]) ->ignoreErrorsOnPath(__DIR__ . '/cache/DIC.php', [ErrorType::SHADOW_DEPENDENCY]) ->ignoreErrorsOnPackage('symfony/polyfill-php73', [ErrorType::UNUSED_DEPENDENCY]) ->ignoreErrorsOnPackageAndPath('symfony/console', __DIR__ . '/src/OptionalCommand.php', [ErrorType::SHADOW_DEPENDENCY]) //// Ignoring unknown symbols ->ignoreUnknownClasses(['Memcached']) ->ignoreUnknownClassesRegex('~^DDTrace~') ->ignoreUnknownFunctions(['opcache_invalidate']) ->ignoreUnknownFunctionsRegex('~^opcache_~') //// Adjust analysis ->enableAnalysisOfUnusedDevDependencies() // dev packages are often used only in CI, so this is not enabled by default ->disableReportingUnmatchedIgnores() // do not report ignores that never matched any error //// Use symbols from yaml/xml/neon files // - designed for DIC config files (see below) // - beware that those are not validated and do not even trigger unknown class error ->addForceUsedSymbols($classesExtractedFromNeonJsonYamlXmlEtc)
All paths are expected to exist. If you need some glob functionality, you can do it in your config file and pass the expanded list to e.g. ignoreErrorsOnPaths
.
Detecting classes from non-php files:
Some classes might be used only in your DIC config files. Here is a simple way to extract those:
$classNameRegex = '[a-zA-Z_\x80-\xff][a-zA-Z0-9_\x80-\xff]*'; // https://www.php.net/manual/en/language.oop5.basic.php $dicFileContents = file_get_contents(__DIR__ . '/config/services.yaml'); preg_match_all( "~$classNameRegex(?:\\\\$classNameRegex)+~", // at least one backslash $dicFileContents, $matches ); // or parse the yaml properly $config->addForceUsedSymbols($matches[1]); // possibly filter by class_exists || interface_exists
Similar approach should help you to avoid false positives in unused dependencies. Another approach for DIC-only usages is to scan the generated php file, but that gave us worse results.
Scanning codebase located elsewhere:
- This can be done by pointing
--composer-json
tocomposer.json
of the other codebase
Disable colored output:
- Set
NO_COLOR
environment variable to disable colored output:
NO_COLOR=1 vendor/bin/composer-dependency-analyser
Limitations:
- Extension dependencies are not analysed (e.g.
ext-json
)
Contributing:
- Check your code by
composer check
- Autofix coding-style by
composer fix:cs
- All functionality must be tested
Supported PHP versions
- Runtime requires PHP 7.2 - 8.4
- Scanned codebase should use PHP >= 5.3