Import block creation option alongside generated Terraform config

[anup2230]

I would like Former2 to automatically generate the required import blocks alongside the standard Terraform resource blocks in the output. The generated code would look similar to the example provided:

import {
  to = aws_s3_bucket.example
  id = "my-existing-bucket-id"
}

resource "aws_s3_bucket" "example" {
  # ... generated configuration ...
}

The id field would be automatically populated with the actual resource ID discovered during the Former2 scan, and the to field would link to the generated resource address.

This would allow for teams to use former2 to easily import multiple resources from an AWS account into a project's state file to be managed by terraform/opentofu

[iann0036]

Hi @anup2230,

Thanks for raising. It's a common request, however the exact unique identifiers that Terraform uses for this operation are unique to it and aren't super well documented, so we'd need "one of every animal" provisioned resources to check these.

Happy to accept PRs if you wanted to give it a go, I just don't have the time for it at the moment myself.

[anup2230]

Hi @iann0036,

Thanks for the response. I’d be interested in taking a stab at implementing this feature. To give me a head start, could you point me in the right direction?

1. Code pointers: Where in the Former2 codebase are resource configurations generated? I’d like to understand how the current Terraform output is built and where we could inject the import blocks.

2. Resource ID mapping: Are there any existing data structures or functions that already map a scanned resource to an identifier that might be close to Terraform’s import ID? For example, during an account scan does Former2 already store something like an ARN, a name, or a resource ID that we could reuse?

I’m happy to start small—perhaps with a handful of common resources like S3 buckets, EC2 instances, and IAM roles—and then expand. Any guidance you can offer would be much appreciated!

Thanks,
Anup.

[iann0036]

Hey @anup2230,

Within js/services holds each individual service. Each service is always split into:

1. The visual look (datatables) on Former2 (https://github.com/iann0036/former2/blob/master/js/services/lambda.js#L5)
2. Scans for existing resources, adding to the datatables (https://github.com/iann0036/former2/blob/master/js/services/lambda.js#L450)
3. The mapping between the retrieved information and the mapping (https://github.com/iann0036/former2/blob/master/js/services/lambda.js#L696)

In mappings, there are "return values" for both CloudFormation return values, Terraforms attributes, and CloudFormation's import attributes (https://github.com/iann0036/former2/blob/master/js/services/lambda.js#L812) - though not every resource is fully mapped with all of these.

I believe Terraform would have a new set of attribute(s) for specifically the import, then we'd roughly replicate what we do to generate a CloudFormation Import template (https://github.com/iann0036/former2/blob/master/js/app.js#L1329).

[anup2230]

Hi @iann0036,

I have taken an initial deep stab at it and you can view it here: #397.

It seems to work for most resources, however there might be a few standout AWS resources where the mappings need to be updated.