Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parser: Support 1st class blocks without exposed schema #36

Closed
radeksimko opened this issue Mar 24, 2020 · 1 comment · Fixed by #287
Closed

parser: Support 1st class blocks without exposed schema #36

radeksimko opened this issue Mar 24, 2020 · 1 comment · Fixed by #287

Comments

@radeksimko
Copy link
Member

radeksimko commented Mar 24, 2020

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.

@radeksimko radeksimko changed the title textDocument/complete: 1st class blocks without exposed schema parser: Support 1st class blocks without exposed schema May 18, 2020
@radeksimko radeksimko added this to the v0.6.0 milestone Jul 17, 2020
@radeksimko radeksimko added the lsp label Jul 29, 2020
@radeksimko radeksimko modified the milestones: v0.6.0, v0.7.0 Aug 7, 2020
@radeksimko radeksimko modified the milestones: v0.7.0, v0.8.0 Sep 2, 2020
@radeksimko radeksimko self-assigned this Nov 2, 2020
@radeksimko radeksimko modified the milestones: v0.8.0, v0.9.0 Nov 4, 2020
@ghost
Copy link

ghost commented Dec 10, 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 ghost locked as resolved and limited conversation to collaborators Dec 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.