(gen2-migration) `refactor` command should handle custom resources

[iliapolo]

Is this feature request related to a new or existing Amplify category?

No response

Is this related to another service?

No response

Describe the feature you'd like to request

Stateful resources in Gen1 custom resource stacks need to be moved to the Gen2 stack in the same exact way that normal categories are moved.

Describe the solution you'd like

The solution should:

1. Inspect the backend-config.json file to extract the names of the custom resources.

"custom": {
  "processingQueue": {
    "providerPlugin": "awscloudformation",
    "service": "customCDK"
  },
  "publisher": {
    "providerPlugin": "awscloudformation",
    "service": "customCDK"
  }
},

The keys of the "custom" property correspond to the Gen1 nested stack name of each custom resource. The example above will create two nested stacks:

• customprocessingQueue
• customPublisher

These will also be the names of the nested stacks in Gen2 (we will code generate them this way).

2. Discover the stateful resources in each nested stack.

Since custom resource stacks can contain any CloudFormation resource, this is tricky because it requires we have an authoritative and exhaustive list of all possible stateful resources in CFN template.

We can't afford to miss any resource here so we need to prompt the customer and ask them for this information.

Proposal:

Prompt the user with a list of all resources in the stack. Something like:

Your "customprocessingQueue" stack contains the following resources. Please mark the stateful ones you want to refactor:

<> `AWS::SQS::Queue (https://sqs.us-east-1.amazonaws.com/185706627232/sqs-queue-projectboards-main)`
<> `AWS::IAM::Policy (my-policy)`

The customer would then select the SQS queue and we will store its logical ID in memory.

Note: To make this process a bit easier, we can use our stateful-resources list to do initial discovery; but we still need the customer prompt for confirmation.

3. Discover the expected Gen2 logical IDs.

Now we need to figure out which Gen2 resources we need to map to. We should use the following heuristic:

• If there is only a single resource of the expected type in the Gen2 stack - assume that is the correct resource.
• If there are multiple resources (for example 2 SQS queus) - prompt the customer again and ask for the correct Gen2 logical ID for each resource.

4. Proceed with standard refactor flow

At this point we should have all the information we need:

• The nested stack name.
• The Gen1 logical IDs of all stateful resources in each stack.
• The Gen2 logical IDs of those same resources.

We should be able to just reuse the existing refactor logic.

Describe alternatives you've considered

None

Additional context

No response

Is this something that you'd be interested in working on?

• 👋 I may be able to implement this feature request

Would this feature include a breaking change?

• ⚠️ This feature might incur a breaking change

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.