CLI: Improve interactive setup

Use case description

Ensure simple and straightforward onboarding experience into Serverless Framework and accompanying Dashboard

Proposed solution

• Work out single “new project setup” path, and for that focus on interactive serverless (deprecate serverless create)
• In interactive CLI support options through which answers to questions can be prefilled (it’ll allow providing ready project recipes in documentation)
• Settle on single source of official Serverless Framework templates, and let https://github.com/serverless/examples/ serve that purpose
• Improve interactive CLI steps that concern dashboard setup, so they do not involve app choice and deployment profile (which was refactored in favor of providers)
• Propose to deploy newly setup project after new project is setup

How to implement it?

Each point should be addressed as individual PR

1. Seclude interactive CLI setup from internals (specified in detail at https://github.com/serverless/serverless/issues/9354)
2. Introduce aws-node and aws-python examples into https://github.com/serverless/examples/. They should reflect more-less same named templates we host internally in a service
3. In service step, support template-path (installs template pointed at provided local path) and name (name of the project) options. They should override related questions
4. Refactor service step, so it downloads templates from https://github.com/serverless/examples/, update proposed projects list, so it lists following templates:
   • aws-node
   • aws-node-rest-api
   • aws-node-express-api
   • aws-node-scheduled-cron
   • aws-node-sqs-worker
   • aws-python
   • aws-python-rest-api
   • aws-python-scheduled-cron
   • aws-python-sqs-worker Ensure to run npm install in service folder, if package.json with provided dependencies is found in a template
5. In service step, support template-url (any GitHub or Bitbucket url to template) and template (name of a template in examples repo) options. They should override related questions
6. In service step:
   • Provide a default value for project name (<template-name>-project)
   • Refactor Y/n prompt into (1) Yes (2) No select
7. (In @serverless/dashboard-plugin):
   • Refactor dashboard-login so login/register works only via website (follows sls login logic). Presented question should be Do you want to login/register to the Serverless Dashboard? with (1) Yes (2) No select.
   • Remove preliminary question: You can monitor, troubleshoot, and test your new service with a free Serverless account."
8. (In @serverless/dashboard-plugin) Refactor dashboard-set-org so if user has no apps setup yet, use app name same as service (do not prompt for app name)
9. (In @serverless/dashboard-plugin) Refactor dashboard-set-org so it doesn’t create and assign any deployment profiles (Addresses https://github.com/serverless/enterprise-plugin/issues/561 partially)
10. (In @serverless/dashboard-plugin) Refactor dashboard-set-org so:
    • If login/register step was not presented, there’s an option “Skip” at the end of the list that allows to opt-out.
    • if login/register step was presented, and user is assigned with just one org, automatically add this org to YAML without raising a question
11. (In @serverless/utils) Remove Serverless: prefix from inquirer prompt
12. (In @serverless/dashboard-plugin) Improve messaging after setting org to print message Your project has been setup with org: "<org-name>" and app: "<app-name>"
13. (In @serverless/utils/@serverless/dashboard-plugin) Remove Serverless: prefix and fix colors for log output during login
14. Refactor all 1. Yes, 2. No prompts into confirm (Y/n) prompts
15. Remove preliminary question “No project detected. Do you want to create a new one?”
16. Remove tab-completion step from the flow
17. Change auto-update step to always enable auto updates (TO BE DISCUSSED)
18. Improve documentation around tab autocompletion and autoupdate settings
19. (In @serverless/dashboard-plugin) Support SERVERLESS_ACCESS_KEY and prefill org based on the org that the key belongs to
20. Refactor aws-credentials step. So:
    1. No AWS credentials were found… message is removed
    2. 'Do you want to set them up now? and 'Do you have an AWS account? prompts are removed in favor of: Do you have an AWS account?, which presents a select with following choices:
       • (if service is setup for dashboard) AWS Access Role (most secure) - When that is chosen, we should open a browser with page that configures a provider for given app, and in CLI we should show prompt Press Enter to continue after configuring service provider credentials (Addresses serverless/enterprise-plugin#561 partially)
       • Local AWS Access Keys, when that is chosen we should follow with same flow we have now for storing local credentials, (user should have browser opened that leads to AWS console, and after that should be asked to input key id and value)
       • Skip
21. Introduce deploy step, which is applied only if service was successfully applied, and (in case of AWS service) if user has credentials setup locally or have set them up via aws-credentials setup… It should be Do you want to deploy now? Y/n prompt. Additionally, replace standard, verbose deploy output with simpler progress steps
22. If service step was presented and user created a new service, after all interactive setup steps finalize show
    • If deploy was performed: Your project is live and available in ./{name}. (in green). Additionally, below show information on how to use info, deploy and dashboard commands
    • If deploy was not performed: Your project is available in ./{name}. (in green)
23. Report all interactive CLI steps choices with telemetry (report only internal questions id, preconfigured answers, and for user free form input, just indicate that input was provided, but do not report the actual input). Also measure steps duration as a part of telemetry.
24. Report with telemetry handlable exit signals (list of them can be found here: https://thomashunter.name/posts/2021-03-08-the-death-of-a-nodejs-process) I believe we should make it generic, so for every command. We should probably just store the event and do not send it (even if it’s deploy command). We probably should report it with outcome: "cancel", to be discussed)
25. Implement support for framework.onboarding event based on proposal (from external Google Doc)
26. Validate telemetry payload with JSON schema (to be implemented in internal private package)
27. Move internal templates to legacy folder in https://github.com/serverless/examples/ repo, and update sls create to install templates from that location.
28. Support non TTY invocation of sls command (to fully provide a sls create replacement). In such case all choices should be read from command line options, and in case of required option being missing, show messages like Cannot setup a service due to missing “template” option. If any of such situations were recorded, after command finalizes present message: Some steps could not be fulfilled. For interactive experience please use a TTY terminal
29. Soft deprecate create command (soft in sense of not making a real deprecation, at least at this point we’re not ready to remove it with next major release):
    • Mark create command as hidden in schema (hidden: true I believe does that), so it’s not exposed in commands help.
    • Whenever user runs sls createshow message: “serverless create” is in consideration to be deprecated. Next time run sls to setup a new service.
    • Scrub all documentation and resources we have access to, and replace sls create usage with sls

[medikoo]

What about new users, coming straight to v3?

They should follow the documentation. In all the usage examples CLI params follow the command

[OJFord]

What about new users, coming straight to v3?