Ability to skip some paths from linting

[mgzenitech]

Versions

This feature does not yet exist in:

• the latest version of the extension (below)
• the latest version of the language server (below)

Extension

Language Server

Problem Statement

Currently every single .tf file is linted. My specific case is that we use ERB to prebuild .tf files and all of the files with ERB template syntax is being shown as having problems even though they are not real .tf files.

(I can do ... today but ...)

When I do ... then ...
It would be helpful if ...

Expected User Experience

I would be able to see ... when I click/type ...

Proposal

References

[radeksimko]

@mgzenitech Can you share some more details about the filenames you have in place and also explain what do you mean by "linting"? Do you mean the basic diagnostics resulting from invalid configuration?

Generally speaking if a file has *.tf extension, it will be considered a valid Terraform config file - whether by this extension or Terraform - in fact the intention here would be to align the two as much as possible.

Assuming your ERB files are called e.g. main.erb.tf - could you not rename them to main.tf.erb for example, to indicate these are ERB templates and not Terraform files?

[mgzenitech]

Hi @radeksimko !
What I've meant is currently VSCode validates all files with .tf extension and I need some paths to directories to NOT be validated...

For example I have directories:

config/terraform/**/*.tf (ERB templates)
build/terraform/**/*.tf (built files)

I would like disable linting/validation on config/terraform/**/*.tf

[radeksimko]

Thank you for the extra context.

Is there a reason you cannot give these ERB templates in config/terraform/**/ the appropriate .erb or .rb extension? i.e.

config/terraform/**/*.tf.erb (ERB templates)
build/terraform/**/*.tf (built files)

That should then exclude them automatically?

---

Alternatively you could assign these files different language in the bottom right bar. I am not sure if there's a way to do this for a whole folder and persist it somehow somewhere in VS Code settings. Either way that should exclude them from being processed by the extension and avoid the diagnostics being published for these files.

It would also help VS Code in highlighting the ERB syntax in those files correctly, either using the built-in Ruby grammar (assuming you use *.rb) or e.g. this extension (for *.erb).

Highlighting of embedded languages (like ERB + TF) is something we have briefly discussed within #403 in the context of markdown, but I think the problem is pretty much the same here. I'm not sure yet how exactly we'll end up solving the problem, but I suppose it's a problem of combined languages within ERB templates, just like Markdown has the same problem - i.e. you are typically templating syntax of another language. So maybe the Ruby or ERB grammar needs to be injecting all kinds of other grammars to account for this.

---

Either way - if there's one language to choose from for the files you described I'd say ERB/Ruby is a better choice than Terraform - and that is what the file extension should also indicate and that's what can help in highlighting these files outside of VS Code too (e.g. on GitHub).

---

I'm not quite convinced there is need for extension-specific mechanism to exclude files - at least I expect VS Code itself to control what languages are assigned to what files and then our extension can act based on these languages (or not).

[mgzenitech]

Impossible to do that as Terraspace framework specifically searches for .tf extensions... Maybe it would be possible to have some sort of skip comments like in other linters:

# ignore-next-lines 4

or something similar?

[radeksimko]

I think there may be misunderstanding wrt the origin of the diagnostics. Generally these do not come from a "linter". This is merely a result of files being loaded & parsed by the extension, either by the *.tf file extension or (crucially) by the language ID. This means in practice that even blablah.txt could be processed by our extension (and diagnostics published for), as long as it is identified as terraform (or terraform-vars) language.

The extension -> language mapping is done by the static extension settings

vscode-terraform/package.json

Lines 56 to 82 in dda20fc

	"contributes": {
	"languages": [
	{
	"id": "terraform",
	"aliases": [
	"Terraform",
	"terraform"
	],
	"extensions": [
	".tf"
	],
	"configuration": "./language-configuration.json"
	},
	{
	"id": "terraform-vars",
	"extensions": [
	".tfvars"
	],
	"configuration": "./language-configuration.json"
	},
	{
	"id": "json",
	"extensions": [
	".tfstate"
	]
	}
	],

and the highlighting (i.e. which file to highlight how) by another static grammar settings

vscode-terraform/package.json

Lines 83 to 94 in dda20fc

	"grammars": [
	{
	"language": "terraform",
	"scopeName": "source.hcl.terraform",
	"path": "./syntaxes/terraform.tmGrammar.json"
	},
	{
	"language": "terraform-vars",
	"scopeName": "source.hcl.terraform",
	"path": "./syntaxes/terraform.tmGrammar.json"
	}
	],

This gives us no way to dynamically exclude any patterns from there.

---

I still believe that ERB templates should be communicated as such instead of reusing Terraform's own file extension (*.tf). Terragrunt ran into a similar problem in the past, where Terragrunt-specific configuration (unknown to Terraform itself) was stored under terraform.tfvars files. See more at gruntwork-io/terragrunt#466

I would encourage you to raise this to Terraspace and propose that they establish a convention such as *.tf.erb instead of *.tf such that it's clear for all tooling (including this extension) that these files are ERB templates, not necessarily valid Terraform files.

---

We may consider somehow highlighting files which embed Terraform syntax in the future but this would likely only involve highlighting since LSP doesn't provide any "native" way to process embedded files and highlighting of such files also isn't simple today (involves various hacks).

Either way for any such combined files (Markdown or ERB) there still has to be clarity about what these files are and naming them *.tf doesn't provide that clarity - *.tf.erb does, or possibly terraform IDs within codeblocks of *.md files do.

With that in mind I'm going to close this in favour of #403 which I rewrote to include ERB as well. Feel free to follow that issue.

[github-actions]

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 details necessary to investigate further.