Closed odeadglaz closed 5 months ago
Hey, I opened a draft PR for a potential fix here would love for any comments š
I recommend using something like node-dev.
If you don't want that, or it doesn't work for some reason, another solution you could use today is to set restartTries: -1
. This makes killed processes restart forever, so you don't need to manually restart. Completion is autmoatically handled in this case.
But for restarting at a random moment, there'll will still be issues, as you demonstrate.
Hey,
First thanks for the proposals, appreciated š
Both of these won't really do for me:
node-env
won't just do, as I need to wait for successfull compilation of the main app or one if its workspace dependencies ( we are working with npm workspaces )restartTries
as some commands that fail, should crash the process (unlike the restartable command)I think i will create a process, that just stays up for ever and manage a subprocess with restarts undertneeth, where as far as concurrently all commands will ever run if we won't have a near term solution
I don't wanna use
restartTries
as some commands that fail, should crash the process (unlike the restartable command)
If your app doesn't need to gracefully exit, you should be able to send a SIGKILL instead of a SIGTERM in this case
It doesn't as we are using this for local development mode, tho I'm not sure how using SIGKILL will help here? Won't it emit close
event of that command as-well ?
Description I'm using
concurrently
to run 2 commands in parallel on my application:swc
node ./dist/server.js
command which starts my HTTP server.I wanted to implement a logic of which every time
SWC
outputs a successful watch compilation output, to restart theNodeJS
server by combining theCommand
objectkill/start
API.Here is a simplified example of my code:
Actual Behaviour After 2 restarts the
concurrency
top command resolves as both commands was terminated but in fact, both commands still up and running.Some Technical details It seems that
CompletionListener.listen
method actually usesbufferCount
to assume its commands were terminated by counting theclose
events but programmatically usingCommand.start
/Command.kill
API's can cause un-expected behaviour in this manner as nothing was actually terminated rather solely restartedThanks in advanced š