You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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.
The text was updated successfully, but these errors were encountered:
radeksimko
changed the title
textDocument/complete: 1st class blocks without exposed schema
parser: Support 1st class blocks without exposed schema
May 18, 2020
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the context necessary to investigate further.
ghost
locked as resolved and limited conversation to collaborators
Dec 10, 2020
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
count
for_each
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.
internal/terraform/lang
)>=0.12.0
andFindCompatibleParser
only finds a single parser. We can use this scaffold to reflect the reality of syntax changing between TF versionsinternal/terraform/lang/hcl*
tfjson
structs, but we could try to turn these structs into compatible interfaces and have a similar static implementation ("schema dispenser") for the above blocksprovisioner
,count
etc.)For reasons above I would encourage discussing the design of the possible solution(s) here before attempting to raise a PR.
The text was updated successfully, but these errors were encountered: