Amplify-cli: Highlight delete confirmation a bit more as warning

Created on 11 Dec 2020  路  5Comments  路  Source: aws-amplify/amplify-cli

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

As a developer, I want to be warned a bit more when I run a command that affects production like amplify delete so that I can avoid risk in production.

Screen Shot 2020-12-11 at 14 10 32

Describe the solution you'd like

Highlignt by red for confirmation promp if it affects production. Currently, there is log level from cli perspective and having the similar level for cli users would be quite helpful to avoid the risk that I mentioned in the user story.

The log level in my mind so far is the below:

Red: Affect production
Yellow: Affect the other resources
Green: Affect no resource on AWS

Additional context

I heard from a developer who does not use English as a primary language that they ran amplify delete to try deleting an env instead of all hosting service and production was down after. The reason why they ran is because the warning message did not look like dangerous comparing to error message(log level=error). Even the default is No and description is clear, making the prompt a bit more noisy is maybe not too much for persona I mentioned, imho.

enhancement platform

Most helpful comment

Agree that this is an issue. Let's make the text red and add a "鈿狅笍" at the front. Curious what others think as well.

All 5 comments

Agree that this is an issue. Let's make the text red and add a "鈿狅笍" at the front. Curious what others think as well.

Alternative solution that I can come up with is i18n in cli, but it's quite challenging from my experience at npm command to keep time2market fast in upstream. Might be good as long-term goal 馃

@renebrandel Adding of emoji's might be challenging to take into account with our E2E test expect scripts. @ammarkarachi @yuth where all do we need to make changes w.r.t to our E2E tests for this change?

I just also had a chat with a developer on this now and came up with a protected env concept. That can specify env that should be protected such as production environment and/or test environment.

Three protected (aka locked/unlocked) concept we've discussed before especially for data retention and recreation of tables. That might be the best option here. We will discuss in the new year in depth.

Was this page helpful?
0 / 5 - 0 ratings