[TASK] Avoid composer 'scripts' and 'scripts-descriptions'

[lolli42]

Fluid standalone devs should rely on the calls performed by GH workflows. It is a burden to keep composer scripts in sync.

[mbrodala]

Why not Zoidb^ both? Actually it's a good pattern to have the CI call commands exactly like a human developer would do. This guarantees the same results. So instead of dropping the Composer commands the Github workflows should actually run these commands. If parallel jobs are not a must, you can even have a single composer build command run by the CI.

Example:

• https://github.com/pagemachine/typo3-formlog/blob/46249fd651d015a7b2f8df2936dd2b6dc43c4f70/.github/workflows/ci.yml#L36
• https://github.com/pagemachine/typo3-formlog/blob/46249fd651d015a7b2f8df2936dd2b6dc43c4f70/composer.json#L88

[lolli42]

Sorry, but no.

In general, I'm not a fan of composer scripts in the first place: They start with naming issues you then have to remember, gives additional headaches with additional arguments, is opinionated, and need maintenance.

In this very case, the 'dev' tasks are really simple:

composer update
vendor/bin/php-cs-fixer fix
vendor/bin/phpstan analyze
vendor/bin/phpunit

Plus the optional casual command options these binaries provide, if a dev wants that. Maybe also with a different php executor like this: /usr/bin/php8.3 vendor/bin/phpunit.

For this library, I see neither the need to encapsulate (and maintain) these binary calls every dev should know in composer.json, nor to abstract this away via something like runTests.sh - I think it's fair to require a local PHP in fluid standalone for devs who wish to develop things.