Closed daveaglick closed 3 years ago
Ended up implementing this a little differently and switching behavior based on preview vs. non-preview. When in a preview command, the background processes will continue to run until they exit without blocking anything. In a non-preview command, background processes will block before the next process timing phase can run.
This also means we need to be careful about which processes to launch depending on phase - launching a background process like gulp with a watch that never exits naturally would block normal non-preview executions now. To address this, registering a process can now specify whether to run when previewing, when not previewing, or always.
This will ship in the next release.
@daveaglick might be good to grab a chat about this at some point to see how this can be used for our setup 😄
Ended up reworking this just a bit before shipping. Decided not to make any assumptions about preview vs. non-preview and whether we should block on process exit. Instead there's a flag to indicate whether you want a background process to block until exit before the next process timing phase.
It may be advantageous to have a process run in the background during execution so it can run concurrently with Statiq (I.e. a gulp process that doesn't use input files), but also allow it to finish before exiting (or re-running) instead of just killing it. Not quite a background process - more like a concurrent processes. This is more of a performance boost than anything, but it could cut the generation time in half if the process takes just as long as execution if we don't have to wait for it.