# Troubleshooting
# A class is not prefixed
PHP Prefixer can identify most cases to apply the prefix. However, there are challenging cases that can't be immediately prefixed. For instance, if the class name is created dynamically, concatenating strings, the prefixer can't identify and prefix the class. In general, these cases are rare. Please, check the following issues.
# Hidden Dependencies: Classes from a library are not prefixed
PHP Prefixer processes the declared dependencies to prefix all files. It processes only the required files according to the identified dependencies. The project files in the source folder will be prefixed for all libraries, and the libraries will be processed for the identified relationships.
The set of installed libraries may have a hidden dependency that PHP Prefixer can't discover automatically.
To solve the issue, the PHP Prefixer extra configuration can be extended to include the dependency. Please, check the advanced configuration here: https://php-prefixer.com/docs/config-reference/ (opens new window)
...
"extra": {
"php-prefixer": {
...
"add-dependencies": {
"illuminate/support": [
"psr/log"
],
"nesbot/carbon": [
"illuminate/support"
],
"php-http/client-common": [
"guzzlehttp/psr7"
],
"php-http/curl-client": [
"guzzlehttp/psr7"
],
"php-http/discovery": [
"guzzlehttp/psr7",
"php-http/message",
"psr/log"
],
"php-http/message": [
"guzzlehttp/psr7"
],
"symfony/translation": [
"psr/log"
]
},
...
# Runtime Dependencies: PSR-17 - HTTP Factories are not prefixed
PSR-17: HTTP Factories is another case where the interface implementation is wholly decoupled, and the association between the library and the HTTP client is decided at runtime.
To solve the case, you can declare the relationship between the library and the HTTP client in the PHP-Prefixer extra configuration. Alternatively, if the library allows it, you can declare the HTTP Client explicitly to avoid runtime uncertainty.