(stale) modules & providers remain installed after terraform init

[radeksimko]

Terraform Version

v1.0.11

Terraform Configuration Files

module "name" {
  source = "./local"
  foo    = "blah"
}

# To be commented out or removed
module "eks" {
  source = "terraform-aws-modules/eks/aws"

  cluster_version = "1.21"
  cluster_name    = "my-cluster"
  vpc_id          = "vpc-1234556abcdef"
  subnets         = ["subnet-abcde012", "subnet-bcde012a", "subnet-fghi345a"]

  worker_groups = [
    {
      instance_type = "m4.large"
      asg_max_size  = 5
    }
  ]
}

Expected Behavior

Previously installed removed module (eks in the example above) to be removed from the module manifest and filesystem (assuming it's downloaded from a remote location) upon removal from the configuration and running get or init.

Actual Behavior

Entry for the removed module stays in the manifest and remains cached on the filesystem.

.terraform/modules/modules.json

{
    "Modules": [
        {
            "Key": "",
            "Source": "",
            "Dir": "."
        },
        {
            "Key": "eks",
            "Source": "terraform-aws-modules/eks/aws",
            "Version": "17.24.0",
            "Dir": ".terraform/modules/eks"
        },
        {
            "Key": "eks.fargate",
            "Source": "./modules/fargate",
            "Dir": ".terraform/modules/eks/modules/fargate"
        },
        {
            "Key": "eks.node_groups",
            "Source": "./modules/node_groups",
            "Dir": ".terraform/modules/eks/modules/node_groups"
        },
        {
            "Key": "name",
            "Source": "./local",
            "Dir": "local"
        }
    ]
}

$ du -h -s .terraform/modules/eks
2.1M	.terraform/modules/eks

Steps to Reproduce

1. terraform get
2. remove whole module "eks" block
3. terraform get

Additional Context

We leverage the internal state (acknowledging it's not a stable/public API) in .terraform/modules to display details about installed modules in the Terraform VS Code extension and we noticed that we may often present stale data as a result of the above.

[radeksimko]

After thinking through this and typing it all out 🦆 I'm realizing we could and should probably use the configuration as a primary source of truth in our use case and then use the internal state as secondary to provide the hierarchy, installed version, installed path etc.

So it's no longer a blocker for us, but it is still somewhat surprising behaviour for me, so I'm going to leave this open in case you want to address it. I would expect this behaviour to potentially be problematic from disk usage perspective over the long run.

btw. the same problem applies to provider installation.