to address https://github.com/civicrm/composer-compile-plugin/issues/13

This checks what happens if adding a package A that requires package B that requires package A.

It seems to have made a change so that eventname can't be null for EventDispatcher. Admittedly 2.3 was just released today, but civi download fails at the compilation task.

Error: Argument 1 passed to Composer\EventDispatcher\Event::__construct() must be of the type string, null given, called in .../vendor/civicrm/composer-compile-plugin/src/Event/CompileTaskEvent.php on line 55
In Event.php line 49:
                                                                               
  [TypeError]                                                                  
  Argument 1 passed to Composer\EventDispatcher\Event::__construct() must be of the type string, null given, called in .../vendor/civicrm/composer-compile-plugin/src/Event/CompileTaskEvent.php on line 55          
                                                                               

Exception trace:
  at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/Event.php:49
 Composer\EventDispatcher\Event->__construct() at .../vendor/civicrm/composer-compile-plugin/src/Event/CompileTaskEvent.php:55
 Civi\CompilePlugin\Event\CompileTaskEvent->__construct() at .../vendor/civicrm/composer-compile-plugin/src/TaskRunner.php:205
 Civi\CompilePlugin\TaskRunner->runTask() at .../vendor/civicrm/composer-compile-plugin/src/TaskRunner.php:169
 Civi\CompilePlugin\TaskRunner->run() at .../vendor/civicrm/composer-compile-plugin/src/TaskRunner.php:74
 Civi\CompilePlugin\TaskRunner->runDefault() at .../vendor/civicrm/composer-compile-plugin/src/Command/CompileCommand.php:75
 Civi\CompilePlugin\Command\CompileCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Command/Command.php:298
 Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:1015
 Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:299
 Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:334
 Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:171
 Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:130
 Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:83
 require() at /usr/local/bin/composer:29

Apparently some distributions of php have Thread Safety => disabled (e.g. php -i | grep Thread). This makes getenv always return false, so it can't get the task. I don't have an immediate workaround other than to do it on another system and transfer it over, or instead write to known fixed filename and then read that back. Mostly putting this here in case other people run into this.

It's in src/TaskTransfer.php in export() and import().

WARNING: Failed to read compilation-task from COMPOSER_COMPILE_TASK. Please use "composer compile".
PHP Fatal error:  Uncaught InvalidArgumentException: Invalid file reference (tpl-file=NULL) in .../sites/all/modules/civicrm/vendor/civicrm/composer-compile-lib/src/Tasks/Template.php:62
Stack trace:
#0 .../sites/all/modules/civicrm/vendor/civicrm/composer-compile-lib/src/Tasks/Template.php(21): CCL\Tasks\Template::assertFileField(Array, 'tpl-file')
#1 .../sites/all/modules/civicrm/vendor/civicrm/composer-compile-lib/src/Tasks.php(24): CCL\Tasks\Template::compile(Array)
#2 Command line code(1): CCL\Tasks::template(Array)
#3 {main}
  thrown in .../sites/all/modules/civicrm/vendor/civicrm/composer-compile-lib/src/Tasks/Template.php on line 62
> @php -r 'require_once '\''.../sites/all/modules/civicrm/vendor/autoload.php'\''; Civi\CompilePlugin\TaskTransfer::import(); \CCL\Tasks::template($GLOBALS["COMPOSER_COMPILE_TASK"]);'
Script @php -r 'require_once '\''.../sites/all/modules/civicrm/vendor/autoload.php'\''; Civi\CompilePlugin\TaskTransfer::import(); \CCL\Tasks::template($GLOBALS["COMPOSER_COMPILE_TASK"]);' handling the shell-runner event returned with error code 255

Warning: Use of undefined constant COMPOSER_COMPILE_TASK - assumed 'COMPOSER_COMPILE_TASK' (this will throw an Error in a future version of PHP) in Command line code on line 1

This line puts double-quotes around it: https://github.com/civicrm/composer-compile-plugin/blob/af9686c4511ad4d2dde3c32aafa4637579e1085d/src/Handler/PhpMethodHandler.php#L21

On windows the double-quotes disappear at some point along the way and so php thinks you're using a constant that hasn't been defined.

Since shell escaping is hard enough as it is and on windows is extra-bizarre, just putting this as a placeholder for now. With a quickie test it works to just put single quotes in that code line, i.e. \'. I might test that out a bit more.

There seems to be an error occurring when installing some drupal modules via composer when civicrm is already installed.

Back trace shown:

Exception trace:
 () at /vendor/civicrm/composer-compile-plugin/src/Util/ComposerPassthru.php:72
 Civi\CompilePlugin\Util\ComposerPassthru->run() at phar:///usr/local/bin/composer/src/Composer/Plugin/PluginManager.php(196) : eval()'d code:117
 Civi\CompilePlugin\CompilePlugin_composer_tmp5->runTasks() at n/a:n/a
 call_user_func() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:164
 Composer\EventDispatcher\EventDispatcher->doDispatch() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:96
 Composer\EventDispatcher\EventDispatcher->dispatchScript() at phar:///usr/local/bin/composer/src/Composer/Installer.php:338
 Composer\Installer->run() at phar:///usr/local/bin/composer/src/Composer/Command/RequireCommand.php:248
 Composer\Command\RequireCommand->doUpdate() at phar:///usr/local/bin/composer/src/Composer/Command/RequireCommand.php:205
 Composer\Command\RequireCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Command/Command.php:245
 Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:835
 Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:185
 Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:281
 Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Application.php:117
 Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:113
 Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:61
 require() at /usr/local/bin/composer:24

I can reproduce this on a clean install by doing the following: composer create-project drupal/recommended-project civicrm cd civicrm/ composer config extra.enable-patching true composer config minimum-stability dev composer require civicrm/civicrm-{core,packages,drupal-8}:'~5.32' composer require drupal/drupalauth4ssp

Failure happens at the last step. Have also tried --with-all-dependencies and wiping vendor and composer.install in case this helps.

I suspect this might be related to: https://lab.civicrm.org/dev/drupal/-/issues/150

this plugin is not compatible with PHP 8.1 / PHP 8.0 smoke billows out of this area:

  Composer\EventDispatcher\Event::__construct(): Argument #1 ($name) must be of type string, null given, called in vendor/civicrm/composer-compile-plugin/src/Event  
  /CompileTaskEvent.php on line 55```

Consider this update:

• Checkout civicrm-core at revision 6f776cf7a8. The composer.lock uses composer-compile-plugin@v0.8.
• Run composer install
• Checkout civicrm-core at revision 29ff32ead9. The composer.lock uses composer-compile-plugin@v0.10. Additionally, there's a new item in the task-list -- based on the newer @php-script type.
• Run composer install

This fails:

The problem is that composer initialized with plugin v0.8 (which lacks @php-script support), fetched all the new packages, and then tried to process the new tasks using the old code (still retained in memory).

I think the solution is to change this detail about the hook:

• Right now, there's a listener for POST_INSTALL_CMD which instantiates TaskList and TaskRunner.
• Alternatively, the listener for POST_INSTALL_CMD should start a new subprocess with @composer compile. In the new subprocess, it would load the newly downloaded code. (The main process would still exist, but it wouldn't do anything substantive, so it doesn't matter if it has the old code in memory)

Now, as long as the old+new versions both follow this convention, you'd expect that version-switches would be more robust...

Example error below:

Generating autoload files
3 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Error: implode(): Invalid arguments passed
In ComposerPassthru.php line 62:
  implode(): Invalid arguments passed
install [--prefer-source] [--prefer-dist] [--prefer-install PREFER-INSTALL] [--dry-run] [--dev] [--no-suggest] [--no-dev] [--no-autoloader] [--no-progress] [--no-install] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--] [<packages>...]
Error: Process completed with exit code 1.

Update the test matrix to include PHP 8.1. Add a few updates to address some issues with running tests. There should be no changes affecting a typical runtime.

• LocatorTest - Upstream is failing to install on composer v2. Skip for now.
• DownloadTest - Upstream is now working on composer v2. Enable it.
• VeryLargeTaskTransferTest - Fix warning on PHP 7.4

The CiviCRM CI threw up an error when installing on Drupal 8.7.11, which has a peculiar situation in the dependency-graph. The root package (drupal/drupal) both

• Replaces drupal/core-file-cache, and
• Requires drupal/core-file-cache

This patch makes two changes (one long, one short):

• (Long) Fully resolve aliases upfront, before sorting. To wit: drupal/core-file-cache should be treated as drupal/drupal.
• (Short) Skip self-requirements. To wit: it's silly for drupal/drupal to require drupal/drupal

If you run composer install or composer compile, and if it has enough information about the inputs (watch-files) and outputs (out-files), then it will do a staleness check before compiling.

If we don't have enough information, then err on the side of recompiling too much.

I'm probably going to leave this sitting in a PR for a while because it adds some systemic complexity and I'm a little ambivalent about cost/benefit (maintenance/risk/performance/need/utility). Gonna let this marinate...