composer: Composer script timeouts not behaving as expected

I want to stress from the title, AS EXPECTED. This whole issue may be because my expectations are incorrect.

---

We use Composer’s scripts quite extensively. We even use it to automate our dev Docker environments, so commands like composer serve will run a Docker Compose command behind the scenes. Basically, everything goes through Composer. So we can flush caches, build the front-end etc, all through Composer scripts.

We like this solution because it’s one place to go to. It’s easy for devs to learn, and let’s be honest, pretty much everyone working with PHP understands Composer, right? Because everything runs inside Docker, our dev environments essentially have three dependencies: PHP, Composer and Docker. This works better cross-OS than using shell scripts, for example.

Anyway, this has gone really well, except for a couple of problems:

We have a composer webpack command, which spins up a Node container and runs a webpack --watch command which will spot any changes to our SCSS, for example, and automatically build it, rather than us needing to manually compile after every save. This will eventually timeout, as expected. We have two options that we can see: Increase the process timeout to something enormous (feels wrong), or we pass in the --timeout=0 argument to disable the timeout for this script. And here’s the problem:

1. We can’t make it part of the Composer Script config, it has to be part of the command that the dev enters, which means that the convenience is reduced. The command currently looks like this:

   "scripts": {
     "node": "docker-compose run --rm -w /app node",
     "webpack": "@node webpack --watch"
   }
   

   (the node entry is there for convenience since we reuse it for a few commands).

   I wanted the command to be more like this:

   "scripts": {
     "node": "docker-compose run --rm -w /app node",
     "webpack": "@node webpack --watch --timeout=0"
   }
   

   This does not work as the timeout argument is passed to the container, not Composer. Can we do this, somehow?

2. The other problem is that for us to pass in the --timeout=0 argument, we can’t use the shorthand composer webpack. We have to use composer run webpack. OK, it’s only four extra characters, but it’s reducing convenience again. Developers either need to get out of the habit of just running composer test, or composer serve and to start typing composer run test, or they need to remember that the Webpack script is an exception to the rule, and they’ll need to not only add the timeout, but also the additional run parameter.

I had a quick look, and in all honesty, it wasn’t something that was immediately obvious on how to fix (for either problem).

Can you advise is this actually a fault? Can either be fixed? And if so, can anyone point me in the right direction so that I can give it a go and submit a PR?