-
Notifications
You must be signed in to change notification settings - Fork 46
Description
The Problem
This binary package has numerous hard dependencies that break installatiion for things like PHPUnit, Symfony, etc.
Also, including phpmnd as a nominal composer package increases the burdens of the IDEs such as PhpStorm in needing to parse both phpmnd and any and all of its dependencies that the parent project has no need of.
The Research
From what little I can tell, I don't think there's any reason to package this as a typical PHP library.
How many projects actually use phpmnd's source code in their own apps?
Well, I happen to archive literally every single PHP packagist project, weekly, and so I'm going to check... Specifically, i'm going to have my own local LLM parse through for any instance of "use Povils\PHPMND".
STandby...
[5 minutes later] OK I"ve searched 100% of the PHP Packagist repos as of 2024-12-31 (the last time the quarterly full analysis was done). All 416 GB. Full search log.
The following have actual dependencies on PHPMND source code:
- Searching m for Povils\PHPMND...
m/macfja/phpqa-extensions/src/Tools/Analyzer/PhpMagicNumber.php
19: 'internalClass' => 'Povils\PHPMND\Console\Application',
So literally just that one project, that's been dead since 2021, uses phpmnd source code.
The Solution
- Transition this project to a phar binary only via
composer. - Do not distribute the source code into the
vendordirectory of projects. - Do not require the dependencies of phpmnd into the parent projects.