Allow custom startup commands

Is your feature request related to a problem? Please describe.

When starting the emulator with a dev server, we need to start the dev server separately before starting swa.

Describe the solution you’d like

Allow an app startup command and working folder to be provided. The emulator starts the command before proceeding. For example, running a startup command in the frontend folder might look like this:

swa start http://localhost:3000 --app-startup-command "npm start" --app-location ./frontend

Or if we can make this work cross platform:

swa start http://localhost:3000 --app-startup-command "cd frontend && npm start"

Perhaps also support --api-startup-command? Not sure if this is needed right now.

Describe alternatives you’ve considered

Start the process separately.

Additional context

Also needs this functionality as we have to wait for the servers to be up before proceeding: #146

[anthonychu]

I think there’s a different between “build” and “run”/“startup command”. Build implies run to completion, then start emulator. The command I’m looking for is run and start emulator when port is available. So I think this would work better as something other than a build command.

[manekinekko]

Good catch! What’s happening here is that when we start with a dev server context (swa start http://localhost:3000 ...), we await (waitOn) for that dev server to be ready before moving on.

This process will block the rest of the script and hence we don’t reach the --run logic. The CLI will exit(-1) after waitOn times out.

To fix this, I suggest that we skip awaiting for the dev server if we are also passing in a --run command. This way we:

1. start swa and setup the proxy requests for the dev server
2. in parallel, we process the --run command (which for instance starts the dev server)

However, if we follow this logic, then running the following command swa start http://localhost:3000 --run "echo Hey", where the --run script doesn’t start a dev server, then all proxied requests to http://localhost:3000 will fail if the dev server isn’t started. (and we skipped checking if the dev server is ready).

On the other hand, if we don’t passe in a --run script, then we will have to await for the dev server to be ready (what we are doing rn).