up start improvements

[tj]

Just an issue for #239, the gist of it is to provide local build/clean hooks so that up start starts the proxy and runs node app.js, or go run main.go etc for you.

The alternative is to replace up start with a less magical up proxy PORT, so instead of running:

$ up start

You'd run something like the following, where 5000 is the port app.js is listening on.

$ node app.js
$ up proxy 5000

and visit the proxy's port instead of your app's. This might be a bit more confusing, but you also need to be aware of less magic which could be potentially confusing as well if you start deviating from the conventions (of ./app.js, and ./main.go etc), because then you'd need something like:

{
  "proxy": {
    "local_command": "go run cmd/api/main.go"
  }
}

Opinions?

---

• [ ] allow local overrides of hooks etc
• [ ] add inferred hooks for Go et al
• [ ] document

[skabbes]

Signal propagation, stdio inheritance, etc make the up start code much more error prone. But if they can be solved with confidence, perhaps up start seems simpler.

Given that up start might need to interact with other systems, probably allowing a --port option would be good. Then when it launches the subprocesses, process.env.PORT can define what port to run on.

up start --port 8080

With up proxy, it would have to look something like this:

up proxy --bind 8080 5000

which might be confusing enough to not use it in my opinion.

Either way I think proxy.local_command will be necessary, since often times in development you won't be launching your code the same way as in prod, you will be using some kind of dev server (hot reloading, etc).

[tj]

If we don't have up start, you'd just go run main.go or whatever as you would normally, so that definitely cuts out a lot of weird edge-cases we might hit.

up start is definitely a bit simpler UX-wise which I like, but I'm not 100% sold on it since it's so much easier to just say "run your app however you normally do" haha. I could see up start getting annoying if you want to pass extra flags to node, or -race for go run etc

[kaihendry]

Was thinking it would be really useful if the locally developed lambda could assume the function role.

Right now my iterations are using gin locally, and when I deploy, obviously I have to deal with the inevitable & confusing misalignment with IAM permissions between my own AWS_PROFILE and the role that the lambda runs under.

[tj]

@kaihendry ahhh good idea, I'll see if I can add that!