Custom destinations for modules

[ivan-kostko]

This feature enables module management with specific destinations, while back compatibility is intact.

Centrally managed: Terrafile is located in "root" directory of your terraform code, managing modules in all subfolders / stacks An example of using Terrafile in a root directory:

Let's assume following directory structure structure

.
├── iam
│   ├── main.tf
│   └── .....tf
├── networking
│   ├── main.tf
│   └── .....tf
├── onboarding
.
.
.
├── some-other-stack
└── Terrafile

In above scenarion Terrafile is not in every single folder but in the "root" of terraform code.

An example usage of centrally managed modules:

tf-aws-vpc:
    source:  "git@github.com:terraform-aws-modules/terraform-aws-vpc"
    version: "v1.46.0"
    destination:
        - networking
tf-aws-iam:
    source:  "git@github.com:terraform-aws-modules/terraform-aws-iam"
    version: "v5.11.1"
    destination:
        - iam
tf-aws-s3-bucket:
    source:  "git@github.com:terraform-aws-modules/terraform-aws-s3-bucket"
    version: "v3.6.1"
    destination:
        - networking
        - onboarding
        - some-other-stack

The destination of module is an array of directories (stacks) where the module should be used. The module itself is fetched once and copied over to designated destionations. Final destination of the module is handled in a similar way as in first approach: $destination/$module_path/$module_key.

The output of the run is exactly the same in both options.

[ivan-kostko]

Hi @nritholtz ,

Sorry for off topic, but as we discussed inside our team, the tool is missing -clean flag. The issue appears whenever some module is removed from file, but tool does not remove it from filesystem. Hence, we will prepare a separate PR introducing this functionality as soon as this PR is merged.