`fly new` is documented to default to use the `getting-started` template, but doesn't

[WesleyDavid]

When creating a new Edge App in the UI, we offer a suggestion at their brand new edgeapp.net URL on how the customer can then use the fly CLI to start developing the new app. A customer was tripped up by this:

$ npm install -g @fly/fly

$ fly new

[...]

...because when trying that, you get asked to select a template:

$ fly new
Start a new project with one of the following templates:
  assembly-script
  cache-for-errors
  getting-started
  glitch-custom-hostname
  graphql-stitching
  html-dom
  http-cache
  load-balancer
  object-store
  static-site
  watermark-image
Browse template source at https://github.com/superfly/fly/tree/master/examples

Furthermore, fly new --help tells customers that a new app without a template selected will default to getting-started:

$ fly new --help
Create a new Fly app.

  Usage: fly new [options] [--] [name]

  Options:

    -t, --template [template]  Name of the template to use. default: getting-started
    -l, --list                 List available templates.

Except it doesn't. Looks like this might be the area where the decision making should be altered: https://github.com/superfly/fly/blob/master/packages/core/src/cmd/new.ts#L24

[mrkurt]

Oh, that's suboptimal.

Our CLI options could use some love. The whole app creation process was thrown together pretty quickly so it's all kinds of warty. If you feel like tackling this you should! :D

[chilts]

Thanks @WesleyDavid, this captures what I saw. The other thing I figured is that without the [name] it actually gives the message about the --template so I guess something is getting confused here. :)

I'd be happy to see if I can do a PR for you, but don't let me stop you going ahead since it'll be in my spare time.