We give you the Yireo ExtensionChecker

A new CLI command to check extension code

The Magento 2 application ships with a bin/magento CLI tool, which can be extended upon by Magento developers. I've used this to build a Yireo ExtensionChecker that allows you to check the code of an extension as follows:

bin/magento yireo:extensionchecker:scan SomeVendor_SomeModule

Zero output means that no issues were found. If there is output, issues were found.

Currently, it checks whether dependencies (classes and PHP extensions) found in the extension code are actually declared in the composer.json file and etc/module.xml file of the module. It checks whether the extension is depending on core code that is actually declared deprecated. More features are coming.

Internal workings

The main idea behind the extension is to allow for easier extension reviews of modules built by other vendors. I've often found (bad) Magento modules that were using code of modules like Magento_Catalog but didn't declare this as a sequence in etc/module.xml.

To scan for the extension code, the Yireo ExtensionChecker uses PHP Reflection to open up the PHP code of that extension and read through as if it was PhpStorm. The scan allows for dissecting the PHP constructor of a specific class, seeing which classes are injected as a dependency and analysing those classes as well. In the beginning, I bumped into some performance bottlenecks because of this, but using an internal registry of found classes, this is downsized.

I find the concept of using PHP Reflection to analyse Magento extension code rather cool: It opens up for many opportunities. The reason why this module requires a Magento application is to make sure that Reflection also can use the Magento ObjectManager (including its nifty features like proxies, factories, di.xml and much more). I hope to work on this extension soon again to add more cool features.

I'm using it

The findings were interesting so far. When building a new module, I often play around with DI through PhpStorm, not trying to worry about dependencies while I'm in the flow. This means that once I finish a certain portion of code, I need to think about its consequences for etc/module.xml and composer.json dependencies as well. The Yireo ExtensionChecker takes away this labor: It simply reports what is missing.

While using this for my own extensions, it suddenly hit me that I not only have dependencies with Magento modules but also with PHP extensions (ext-json, ext-pcre). These can be reported through PhpStorm but are often forgotten. A new addition to the Yireo ExtensionChecker allowed me to also detect which PHP extensions should have been added to the composer file. This might sound stupid, but I have encountered weird hosting environments where PHP modules that I see as vital were missing (back then mcrypt, JSON, PDO). Simply adding them to composer.json prevents possible issues in the future.

Findings so far

After running the ExtensionChecker on my own extensions - the first reason why I initially created it - I turned to third party extensions. Extensions that we sense to be bad, indeed often contain bad code and lacking dependency declarations are easily found: No more manual work, but simpy a few commands to create a report about this.

Funnily enough, the feature of scanning for usage of deprecated code didn't give any hit on my own extensions (well done, Jisse), but most of the third party extensions neither. However, when I scanned the core code (modules like Magento_Checkout) a shitload of warnings came up, mostly about the usage of dependencies that were deprecated. This is understanding, even though it worries me a bit less: The Magento code base is enormous and it requires time to remove dependencies.

Upcoming features

The extension at least is already useful for me to guarantee better quality of Yireo extensions. In the near future I hope to implement a couple of more features:

• CLI arguments to disable specfic scans (dependencies, deprecated code);
• Scan the constructor for hardcoded Proxies or VirtualTypes which should only be declared in di.xml;
• Possibly a scan for preference rewrite conflicts, if I find no better alternative in Magerun2;
• Possibly a scan for the keyword @api in dependencies (both classes and methods);

And the hardest feature would be to give suggestions on the versioning of dependencies. Depending on magento/module-catalog of version * should be forbidden. Likewise ^100. But a match like ^100.0 sounds better, but only if there is only a dependency on the API of the module (i.e. interfaces). If there is a dependency on a non-API class, the version should lock on a patch level (^100.4.4 or even 100.4.4). This will be either the Holy Grail or Pandoras Box for validating dependencies.

I hope you find the extension useful. And let me know any issues through the GitHub repo: github.com/yireo/Yireo_ExtensionChecker