Can individual Composer dependencies be suppressed from (auto)loading?

Question

I have a project containing, amongst others, the following composer.json dependencies:

"propel/propel1": "dev-master"`,
"halleck45/phpmetrics": "dev-master"

I recently did a composer update and found that a new version of a library required by PhpMetrics, called Hoa, introduces a new class \EngineException to emulate a new PHP7 class. Unfortunately Propel 1 also defines \EngineException, and so a conflict results.

The correct fix for this would be to upgrade to Propel 2, which uses namespaces. However this is still in alpha and is subject to BC breaks, so is not really workable for me.

My present fix is to lock Hoa to a specific version that does not have the new class:

"hoa/core": "2.15.04.*"

That's not a bad solution, but it isn't entirely satisfying to lock a library to an old version.

In the Hoa code, the only way for the new class not to be loaded is to be running PHP 7, which is again not feasible. However, it also occurs to me that Hoa only needs to be required when PhpMetrics runs. This is a stand-alone code analysis tool and only sits in the root of the project for convenience; the rest of the project does not use this library.

Thus, it would be great if I could call something in Composer to ask that this class is not (auto)loaded, or perhaps something to do the same in the composer.json. It is being needlessly loaded at present - I don't know whether it is being autoloaded incorrectly or whether it is being required manually by Composer.

It may help to know that Hoa classes have been added by Composer to the auto-generated autoload_psr4.php script. As far as I can understand the docs, this means it is autoloaded, and there is nothing in my project that would require any of the Hoa classes.

Answer 1

Fixed by https://github.com/hoaproject/Core/commit/8ed00fe9345c4f8b2679a256926d6d24994ea842.

The new exception architecture introduced in PHP7 [1] has been totally redesigned [2]. This patch updates the retro-compatibility classes according to this new architecture. Consequently, the BaseException class has been removed, along with EngineException and ParseException. While these latters could be implemented (not as is), we prefer to, so far, only implement the Throwable interface. Let see if we can implement (still for the retro-compatibility) the Error, TypeError and ParseError class.

[1]: https://wiki.php.net/rfc/engine_exceptions_for_php7

[2]: rfc/throwable-interface