PHP composer xdebug warning - php

Question

New to PHP. Working on a PHP project and have xdebug enabled to be able to debug my php applications. The production server does not have xdebug enabled because it is handled by another team. On my local machine, when I run composer it gives me a warning saying
You are running composer with xdebug enabled. This has a major impact on
runtime performance.
I do not want to disable xdebug when I am developing. Just wanted to confirm that running xdebug in dev environment should have no impact on the composer installing libraries/performance of the app on the production server.

Answer 1

I do not want to disable xdebug when I am developing. Just wanted to confirm that running xdebug in dev environment should have no impact on the composer installing libraries/performance of the app on the production server.
There is a huge impact of just loading Xdebug. It slows the Composer run down by 3x or 4x, even when the profiling feature is not enabled.
In other words: xdebug is invaluable for debugging, but increases the memory used and processing time of Composer.
How to disable Xdebug for Composer runs?
My suggestion is to write a little invocation helper for running Composer.
The helper is a bash or batch script calling PHP with a custom php.ini, especially configured for Composer. Lets call it: php.ini-composer.
You could copy your current php.ini and adjust it for the Composer run, by removing xdebug or commenting it out, like so: ;zend_extension = "/path/to/my/xdebug.so".
While you are at it: setting memory_limit=-1 is helpful, too.
The full command looks like so on Windows: php.exe -c php.ini-composer composer.phar %*
Just clone the idea for a bash script.
And you may find the full answer to your question in the Composer FAQ.
https://getcomposer.org/doc/articles/troubleshooting.md#xdebug-impact-on-composer
It was added/updated just a few hours ago.
Some alternatives (instead of using seperate ini file) are also mentioned here.

Answer 2

Modern versions of Composer can work around having XDebug enabled by default for the CLI SAPI. It spawns a new PHP process with the XDebug extension disabled in case it is detected.
You can disable this behaviour by setting the following environment variable:
COMPOSER_ALLOW_XDEBUG=1
Found this in the documentation: https://getcomposer.org/doc/articles/troubleshooting.md#xdebug-impact-on-composer

Answer 3

Like with web scripts, expect CLI scripts to run slower as well.
If you need the added runtime performance, you can disable XDebug on CLI only. Set your PHP installation so that it uses different ini files for CLI and your server, as this answer suggests.

Answer 4

To fix this, prior to PHP 7 people would suggest to comment out the extension from your php.ini file.
However, in PHP 7 they are no longer in there.
Instead, we use the phpdismod command.
sudo phpdismod -s cli xdebug
The -s flag tells it to disable Xdebug for the CLI SAPI (/etc/php/7.0/cli) and not FPM.
And just like that, the warning message should be gone. No need to restart PHP.
In addition to this, there is a plugin that downloads packages in parallel to speed up the installation process.

Answer 5

Create a file named php-composer.ini somewhere with the following content (the minimum php config for composer):
extension_dir = "D:/php/ext/" ;according to your system
extension=php_openssl.dll
memory_limit=-1 ;optional
Now create a file named cmz.bat with the following contents. (edit paths accordingly)
#ECHO OFF
php -c "D:\php-composer.ini" "C:\ProgramData\ComposerSetup\bin\composer.phar" %*
add this file to your system path or your project root.
Now use cmz instead of composer and you will not see that message and hopefully the composer speed would be increased.
note: Some package need specific php extensions. you need to add them to php-compsoer.ini file or appending --ignore-platform-reqs switch to cmz.bat file

Answer 6

On a fresh download of Symfony 3.1 and PHP 7.0, you can run the following (having edited it to include the path to your composer.phar file):
php -n -d extension=json.so -d extension=phar.so -d extension=pdo.so -d extension=ctype.so /path/to/composer update
If you have any extra vendors to your composer.json file, you might find that they have a dependency on an extension, so you need to include that by adding -d extension=name_of_extension.so to the list.
What's happening here is the -n flag goes with PHP defaults - it doesn't load any ini PHP config files, so XDebug is never loaded. Then each of the -d flags allows you to dynamically set config values, so you can include extensions.