Disabling xdebug when running composer

Question

When running composer diagnose, I get the following error :

The xdebug extension is loaded, this can slow down Composer a little. Disablin

Answer 1

I usually create a shell script per project, since every project has another PHP version. It's in a /bin/ directory next to composer.phar and composer.json and I run it as ./bin/composer in my project directory.

It looks like this (for php56)

#!/bin/sh
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

COMPOSER_DISABLE_XDEBUG_WARN=1 /opt/local/bin/php56 \
    -d xdebug.remote_enable=0 -d xdebug.profiler_enable=0 \
    -d xdebug.default_enable=0 $DIR/../composer.phar "$@"

The -d options effectively disable xdebug. The COMPOSER_DISABLE_XDEBUG_WARN=1 part disables the warning composer issues.

Disabling the xdebug extension is preferred (see composer troubleshooting), but I personally like the simpler script.

Some timings on my machine: 2 Run with xdebug and ini-enabled: 1m33

Run with xdebug but ini-disabled: 0m19

Run without xdebug: 0m10

Answer 2

If you use PHPStorm, the latest release (2016.2) comes with a feature to enable XDebug for CLI scripts on-demand, which means you can simply turn off XDebug globally on your development machine. The IDE will enable it on the fly when it is needed by code inside your projects.

https://blog.jetbrains.com/phpstorm/2016/06/xdebug-on-demand-for-cli-php-scripts-in-phpstorm-2016-2-eap/

PhpStorm 2016.2 introduces Xdebug On Demand mode where you can disable Xdebug for your global PHP install, and PhpStorm will only enable it when it needs to — when you’re debugging your scripts, or when you need code coverage reports.

You need to edit your PHP Interpreters preferences to include the path to XDebug, as described in the linked article.

To me this seems like the perfect solution, as I only usually want XDebug while I'm in the IDE.

However XDebug does have other potential uses when you are "offline" e.g. extended stack dumps in error logs, which you would lose by turning it off globally. Of course you shouldn't have XDebug enabled on production, so this would be limited to use cases like beta-testing or automated-testing CLI scripts in development.

Answer 3

In most cases you do not need xdebug on CLI mode. If this is acceptable for you than you can configure cli and cgi differently.

So if you make php-cli.ini and conf-cli.d near exiting php.ini file than you can configure cli and cgi differently (for cgi it would be php.ini and conf.d). Just do not put xdebug.ini into conf-cli.d.

Answer 4

By creating an alias you'll suppress that composer xdebug error message.

Just add this line to your ~/.bash_aliases within your system and it should work flawlessly.

alias composer="php -n /usr/local/bin/composer"

Reload the shell to make the new alias composer available.

source ~/.bash_profile

USAGE:

$ composer --version

NOTE:
You don't necessarily need to use any other parameter.
Depending on your system you might have a .bashrc instead of .bash_profile.

UPDATE:

As @AlexanderKachkaev mention in the comments it's worth nothing to add the memory_limit as follows to avoid crashing im some situations:

alias composer="php -d memory_limit=-1 -n /usr/local/bin/composer"

Answer 5

Rather than muddle with temporarily enabling or disabling the PHP module, when you might have concurrent processes using PHP (for example as part of a CI pipeline), you can tell PHP to point at a different module loading directory.

While this is similar to some of the solutions mentioned above, this solves a few edge cases, which is very useful when being used by Jenkins or other CI runner which runs tests on the same machine concurrently.

The easiest way to do this is to use the environment variable PHP_INI_SCAN_DIR

Using this in a script or build task is easy:

export PHP_INI_SCAN_DIR=/etc/php.d.noxdebug php composer install

Of course you would want to prepare /etc/php.d.noxdebug first, doing something like:

mkdir /etc/php.d.noxdebug cp /etc/php.d/* /etc/php.d.noxdebug rm /etc/php.d.noxdebug/xdebug.ini

This means you have an environment similar to the old php environment, with only one module missing. Meaning you don't need to worry about needing to load the phar/json modules as you would with the php -n solution.

Answer 6

I came up with a solution for the Windows-based Composer installer - it should work for any Composer installation, it just basically makes a copy of the loaded INI file and comments out the xdebug zend extension, then loads that configuration file when it runs composer.

I've opened an issue to see if they'd like to integrate this change:

https://github.com/composer/windows-setup/issues/58

You can find my instructions and code there.