Current Situation

LS currently parsers attributes and nested blocks within blocks which have their schema exposed in JSON format via terraform providers schema -json. The following are examples which don't fall into that category:

• variable
• locals
• output
• module
• terraform

and meta parameters such as

• provisioners
• backends
• count
• for_each
• etc.

Parsing of these blocks may therefore need to be approached differently.

How we could tackle this

This will likely require extensive design work to ensure stability and maintainability over time. There is a number of factors to consider, e.g.

• How will the functionality overlap with https://github.com/hashicorp/terraform/blob/master/configs/parser_config.go
  • we probably won't build a separate single library which decouples this logic yet, but should keep this option in mind as the risk of drifting from Terraform is real
• Versioning of language parser (internal/terraform/lang)
  • The parser is currently constrained to >=0.12.0 and FindCompatibleParser only finds a single parser. We can use this scaffold to reflect the reality of syntax changing between TF versions
• How could we leverage the existing HCL parsing logic in internal/terraform/lang/hcl*
  • It is currently coupled with tfjson structs, but we could try to turn these structs into compatible interfaces and have a similar static implementation ("schema dispenser") for the above blocks
• How do we accommodate cases which have part of the schema dynamic (provider, resource, datasource) and part static (meta parameters like provisioner, count etc.)

For reasons above I would encourage discussing the design of the possible solution(s) here before attempting to raise a PR.