Make scripts/composer/ScriptHandler.php a composer plugin

[mminklet]

It seems unusual to me to have a requirement of your repo include the scripts/composer/ScriptHandler.php file. In my view anything that is not custom to the project should not be in the repo and instead installed through the composer.json file, that is how I see things when moving from a drush make file style installation in the past

Am I wrong here? I basically only want a few things in my repo:
composer.json (required)
custom modules/libraries/themes (optional)
my own custom scripts (optional) - arguably I could put scripthandler in here but i I don't have any custom scripts then this is superfluous.

In my head I reckon it should be possible to get the composer.json from this project on it's own as a starting point and install from that without anything additional imo. Is there a way to do that I'm missing perhaps, or am I just missing the point of composer completely?

[brockfanning]

This got me as well. I was not able to do a composer install on a newly provisioned server without having the scripts/composer/ScriptHandler.php file uploaded first.

I agree it would be nice if this file were installed in /vendor as a Composer dependency, and then looked for there.

[PatrickBauer]

Its done with drupal-finder and drupal-scaffold, I don't know why it shouldn't be done for the ScriptHandler (maybe with a better name, ensuring flexibilty).

+1!

[derhasi]

One reason the scripthandler must live in this repo is that it executes before dependencies are fetched: see #170 for details.

We could think of moving ScriptHandler::createRequiredFiles() to drupal-scaffold, but that would be some more work.

[frob]

It would be awesome if we could move as much actual functionality out as possible. This would make it much easier to implement upstream changes.

[geerlingguy]

This also seems to cause #401 in some deployment scenarios (even if the file is present).

[leymannx]

Well, well, difficult. But I'm going to close this as won't fix for now.

On one side the work needs to be done and on the other side the ScriptHandler should probably be seen as a template as well, to be customized. Moving it out of the project doesn't make it customizable so easily anymore. Right now the script handler demonstrates how easily complex tasks using just a little bit of custom code can be done, using the drupal-finder and Symfony components. It would probably be nice to have it code-commented a bit more, though. I'm going to open a task for this.