Publish diagnostics for non-autoloaded variable files (tfvars)

[radeksimko]

Background

In #621 (part of 0.22.0+) we introduced parsing of non-autoloaded *.tfvars files (in addition to the autoloaded ones). This worked with the assumption that we only publish diagnostics when any individual file is opened and clear them when it's closed. This would reflect that invalid *.tfvars which are not autoloaded do not affect regular Terraform operations by default.

However we decided to refactor how diagnostics are handled in #714 which generally decoupled diagnostic publishing away from RPC request handlers, which in turn took away the opportunity to easily and quickly distinguish whether a file is opened or not.

As part of that refactoring we decided to avoid publishing diagnostics for these files as that basically aligns with how gopls handles diagnostics in similar cases - Go build tags.

Use-cases

Users should be able to see diagnostics as they edit any variable file (*.tfvars), but these diagnostics should not be distracting them if the file is actually never used.

Attempted Solutions

Publish diagnostics upon file opening and clear them upon closing.

Proposal

We could introduce a config option ExtraVarFiles []string to existing options

terraform-ls/internal/settings/settings.go

Lines 18 to 31 in 877dcee

	type Options struct {
	// ModulePaths describes a list of absolute paths to modules to load
	ModulePaths []string `mapstructure:"rootModulePaths"`
	ExcludeModulePaths []string `mapstructure:"excludeModulePaths"`
	CommandPrefix string `mapstructure:"commandPrefix"`
	IgnoreDirectoryNames []string `mapstructure:"ignoreDirectoryNames"`
	// ExperimentalFeatures encapsulates experimental features users can opt into.
	ExperimentalFeatures ExperimentalFeatures `mapstructure:"experimentalFeatures"`
	TerraformExecPath string `mapstructure:"terraformExecPath"`
	TerraformExecTimeout string `mapstructure:"terraformExecTimeout"`
	TerraformLogFilePath string `mapstructure:"terraformLogFilePath"`
	}

However this only solves some scenarios as it assumes this setting would be LS-wide for the whole process.

Ideally we should let the user segment this configuration by folder. It is possible that we could leverage workspace/configuration here, but it's unclear what requirements does that have on the client side and which clients actually implement it and how.

Notes

• gopls faces the same challenge as they already tried to apply a similar solution as above x/tools/gopls: improve handling for build tags golang/go#29202
• module/directory differences is not a new problem - we already ran into this in Detect and re-load terraform version & path change #69 and Failed to get schema due to backend authentication #128