"Headless" mode of Amplify CLI is not an idiomatic developer experience

[jamesonwilliams]

Today I recalled that some work had gone in to support a non-interactive mode in the Amplify CLI. I went about trying to use it.

I was expecting a DX like:

amplify subcommand --option1 value1 --option2 value2

Or, at worst:

amplify subcommand --non-interactive --option1 value1 --option2 value2

However, as seen in this doc, the option arguments take JSON blobs. Here's a snapshot, for reference:

AMPLIFY="{\
\"projectName\":\"headlessProjectName\",\
\"envName\":\"myenvname\",\
\"defaultEditor\":\"code\"\
}"
amplify init --amplify $AMPLIFY
# ...

I've never seen a single command line tool like this.

Having the support above does achieve a ground floor functionality to enable automated invocations of the Amplify CLI from a shell script file.

However, it's a counter-intuitive and non-idiomatic developer experience, that is very brittle to use as a human, as a command-line-only interface.

[kaustavghosh06]

@jamesonwilliams Understand the concern here, but having amplify subcommand --option1 value1 --option2 value2 with 20-30 options didn't seem optimal as well when we decided to go with JSON blobs rather which would be easier to manage in CI/CD environments. Having said that we have added support for headless configuration for configuration of categories which look something like cat <your-json-file>.json | amplify add auth --headless and we're working on the docs for the same. We'd like to follow a similar strategy for the init command as well in the future.

[jamesonwilliams]

Thanks @kaustavghosh06 for the very speedy reply.

20-30 options

I don't think there are this many, in practice. Definitely not this many required inputs. Even so, most robust Linux utilities absolutely have scores of options. Look at gcc's man page for an out-of-the-ordinary example.

For this init workflow, the interactive mode collects 6 pieces of information from me. However, the CLI can already detect reasonable defaults for almost all of them:

? Enter a name for the project HostedUITesting
? Enter a name for the environment mymacbook
? Choose your default editor: Vim (via Terminal, Mac OS only)
? Choose the type of app that you're building android
Please tell us about your project
? Where is your Res directory:  app/src/main/res

So, I would expect the non-interactive mode to use those defaults, and give me the option to override them. In other words, if I run this command in an Android project, the CLI should apply the defaults above, that I just clicked through anyway.

amplify init --yes .

To override these options, I should be able to do like:

amplify init --yes \
    --project-name 'HostedUITesting' \
    --environment-name 'dev' \
    --default-editor "$(which vim)" \
    --app-type 'android' \
    --android-res-dir 'app/src/main/res'

^ (--app-type would be exceedingly rare, since we can figure this out most of the time by inspecting the directory contents.)

A user would be able to mix and match these optional flags in most any combination, applying some, none, or all.

[PS-MS]

Are there any updates on this? I'm trying to sort out a build script that pulls the latest environment changes but I'm having trouble working out the Android params

I've had a look through https://docs.amplify.aws/cli/usage/headless/#amplify-pull-parameters and have been able to pull the right environment but it is generating the javascript models, not android, and the documentation isn't clear enough.

The documentation needs to at least display what the options are for each parameter

EDIT: I've managed to do it now by running amplify pull, going through the menu and then building the script from the amplify/.config files. Just leaving this here in case anyone else gets stuck making a headless script for anything but react in vs code.

[jamesonwilliams]

This software is truly just such a remarkable spectacle, lol. Closing some old tickets. You guys are fun.

[wxxedu]

This software is truly just such a remarkable spectacle, lol. Closing some old tickets. You guys are fun.

I totally agree.