starting the Tailwind CLI via aspire to build CSS

[schmitch]

Hello,
currently I tried to start the tailwindcss cli via aspire, unfortunatly I always get the following message:

monitor process exited, shutting down {"pid": 19642}

and after that the tailwindcli gets shut down and does not compile the css, even tough it starts to run correctly. I tried to use AddExecutable or AddNpmApp already, like that:

builder
    .AddNpmApp("Tailwind", "../src/Tailwind/")
    .ExcludeFromManifest();

and our npm script is like that:

{
  "name": "tailwind",
  "version": "1.0.0",
  "scripts": {
    "start": "tailwindcss -i ./styles.css -o ./wwwroot/css/app.css --watch"
  },
  "license": "UNLICENSED",
  "dependencies": {
    "@tailwindcss/cli": "^4.1.11",
    "tailwindcss": "^4.1.11"
  }
}

running it via npm run start works.

Maybe it has something to do with health checks/endpoints, but I have no clue where to start, to make that work

[danegsta]

That particular log message is from monitor processes that gets launched to ensure service processes are cleaned up if the orchestrator doesn't exit cleanly. That particular message means the service process exited, so the monitor is shutting down.

Can you check the dashboard to see what the exit code for the Tailwind service is and what logs were captured?

[schmitch]

currently it had exit code 0 and the logs were fine it basically printed ≈ tailwindcss v4.1.11 than two empty stderr and exited

[danegsta]

It looks like tailwind automatically stops watching when stdin is closed (and we don't attach stdin to child processes currently). You should be to use --watch=always which will keep watching even if there's no stdin.

[schmitch]

wow. that is extremly helpful. I've probably been bitten by that by sbt and playframework aswell.
it would probably be a good idea to either add that to the docs or add some fake stdin for these processes

[danegsta]

Attaching to stdin seems like a reasonable thing for us to be doing. In the long run, we'll likely want to the ability to interact with an application in a terminal interface (either via the dashboard or some other method), so we'd eventually want a real stdin for processes that want it anyway.