Provide diagnostics and quick fixes for invalid configuration

[radeksimko]

Problem Statement

User today already receives diagnostics for invalid HCL syntax, such as missing curly braces, double quotes etc.
User can also trigger the terraform validate command which displays any validation warnings and errors in the form of diagnostics.

terraform validate is usually an expensive operation providing rich validation as defined by provider developers, therefore unsuitable to run as the user types.

User would benefit from a lighter and "cheaper" validation based on provider schema that strikes the balance between the two.

User would also benefit from being able to "quick fix" violations semi-automatically via contextual code actions.

Expected User Experience

Users will be presented with diagnostics the same way that validate or HCL diagnostics are presented:

but these diagnostics will be based on the violation of the (static) schema, for example

• (unknown) references referring to targets that do not exist - e.g. var.example for no corresponding variable "example" block
• literals of incorrect types - e.g. number_field = "string"
• missing required attribute
• missing required blocks (with set minimum instances of block)
• too many blocks (with set maximum instances of block)
• duplicate attributes
• extraneous block labels - e.g. variable "one" "two" {
• missing block labels - e.g. variable {}
• deprecated attributes/blocks

and based on knowledge of mistakes users have made in the past which Terraform CLI already returns, for example

• required_providers in root instead of enclosed within terraform block
• likely typos detected via levenshtein distance (e.g. requred_providers)

All such diagnostics will be presented immediately as the user types.

Proposal

Must haves:

• Introduce a new setting for early validation #1549
• Introduce a new setting to toggle early validation terraform-ls#1336
• Introduce early validation module hook terraform-ls#1338
• Centralize diagnostics publishing terraform-ls#1337
• decoder: Introduce ValidateFilePerSchema() hcl-lang#57
• decoder: Implement reference validation hcl-lang#288
• decoder: Implement validateBody hcl-lang#287
  • decoder: validateBody should support AnyAttribute hcl-lang#289
  • decoder: validateBody should support schema extensions hcl-lang#290
  • decoder: validateBody should ignore missing provider schemas hcl-lang#291
• Optimize the work we do on didChange terraform-ls#1339
• Cache early validation diagnostics terraform-ls#1347

Nice to haves:

• Validate missing required module inputs done
• Validate invalid references inside a resource/block to itself
• Provide diagnostics in tfvars files terraform-ls#1410

Prototype

terraform-ls: https://github.com/hashicorp/terraform-ls/compare/poc-earlyvalidation
ignore the command and code action related changes

hcl-lang: https://github.com/hashicorp/hcl-lang/compare/poc-earlyvalidation

Notes / Postponed ideas

• perform automatic validation against known schema, similar to how Terraform core does it
  • most of the validation can be done in hcl-lang
    • decoder: Introduce ValidateFilePerSchema() hcl-lang#57
    • Provide diagnostics based on mismatching schema terraform-ls#563
  • any further Terraform-specific validation can be added to https://github.com/hashicorp/terraform-schema
• provide "quickfix" Code Actions for violations that can be automatically fixed
  • e.g. adding missing required attribute/block or removing duplicate one
  • e.g. moving required_providers block under terraform block (and/or creating it around)
• All expression types need to be supported for reliable validation meta: Support all Terraform expression types #641
• The concept of Code Actions need to be introduced into hcl-lang in some generic way

[glennsarti]

I ran into this today. Inline tf validate would be so so so so so helpful. Manually running on every save is horrible.

Also the invalidation of the errors is a bit hit and miss.

therefore unsuitable to run as the user types.

I could also argue, why not let users decide what is suitable for them and what is not.

[radeksimko]

Manually running on every save is horrible.

Can you be a bit more specific about what part of it is horrible? It's not clear to me whether you're talking about terraform.experimentalFeatures.validateOnSave or literally running terraform validate from the terminal or via the command palette. Have you tried the experimental feature?

Also the invalidation of the errors is a bit hit and miss.

Can you expand on this a bit more and explain how it is relevant to the original issue outlined above?

---

I'd like to also point out that the intentions outlined in this issue are not to fully re-implement or further deepen integration with the validate command. Instead the intention is to re-implement certain parts of it. Specifically the parts which don't depend on the plugins, which is where the majority of the performance hit (and also UX hurdles) comes from.