Publish diagnostics for hidden `.*.tf` files & non-autoloaded `*.tfvars`

[radeksimko]

Background

The language server will avoid publishing any diagnostics for files which aren't automatically loaded by Terraform.

• *.tfvars which are not terraform.tfvars nor *.auto.tfvars
• *.tf which are prepended by . or #

This is because the only way we publish diagnostics today is through hooks, so there's no simple way of distinguishing between files which the user is actually editing and which ones are just loaded as a side-effect of us loading the whole directory while user is editing a different config file.

terraform-ls/internal/langserver/handlers/hooks_module.go

Lines 128 to 133 in 000cb53

	defer dNotifier.PublishHCLDiags(ctx, mod.Path, diags)
	if mod != nil {
	diags.Append("HCL", mod.ModuleDiagnostics.AsMap())
	diags.Append("HCL", mod.VarsDiagnostics.AutoloadedOnly().AsMap())
	}

terraform-ls/internal/langserver/handlers/command/validate.go

Lines 70 to 74 in 000cb53

	diags.Append("terraform validate", validateDiags)
	diags.Append("HCL", mod.ModuleDiagnostics.AsMap())
	diags.Append("HCL", mod.VarsDiagnostics.AutoloadedOnly().AsMap())
	notifier.PublishHCLDiags(ctx, mod.Path, diags)

UX Impact

Proposal

Diagnostics for non-autoloaded files can be useful to users, so we should present it to them somehow, but we should not distract them with these diagnostics as they may not be relevant.

We could publish diagnostics as part of textDocument/didOpen and textDocument/didChange, assuming we can attach some metadata to the jobs which then end up firing the hooks that publish the diagnostics.

LSP spec states that open events may not necessarily reflect what is or isn't open, but that may be fine for this context. The spec generally doesn't cover this use case and assumes that all files are loaded which doesn't apply well to Terraform here.

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_publishDiagnostics

The following rule is used for VS Code servers that generate diagnostics:

• if a language is single file only (for example HTML) then diagnostics are cleared by the server when the file is closed. Please note that open / close events don’t necessarily reflect what the user sees in the user interface. These events are ownership events. So with the current version of the specification it is possible that problems are not cleared although the file is not visible in the user interface since the client has not closed the file yet.
• if a language has a project system (for example C#) diagnostics are not cleared when a file closes. When a project is opened all diagnostics for all files are recomputed (or read from a cache).

It may be worth opening an issue about this use case in LSP repo. It looks similar to Go's compilation flags.