hashicorp / vscode-terraform

HashiCorp Terraform VSCode extension
https://marketplace.visualstudio.com/items?itemName=HashiCorp.terraform
Mozilla Public License 2.0
925 stars 179 forks source link

"config/terraform/*.tf" locals are ignored since v2.28.0 #1584

Closed alexpilon666 closed 1 year ago

alexpilon666 commented 1 year ago

Extension Version

v2.28.1

VS Code Version

Version: 1.83.0 Commit: e7e037083ff4455cf320e344325dacb480062c3c Date: 2023-10-03T16:11:49.843Z Electron: 25.8.4 ElectronBuildId: 24154031 Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: 11.4.183.29-electron.0 OS: Linux x64 5.15.0-86-generic

Operating System

Kubuntu 22.04.3 LTS

Terraform Version

Terraform v1.6.0 on linux_amd64

Steps to Reproduce

  1. Create file named terraform/config/common.tf at the root of your repository. This file contains multiple local variables, one of which being environment with a value of dev
  2. Create a terraform stack (we use Terraspace) in app/stacks/test and create a locals.tf file.
  3. In locals.tf, create a local value test=local.environment
  4. VSCode's Terraform extension will underline in red the local.environment declaration in locals.tf with the error No declaration found for "local.environment" Terraform

Expected Behavior

Nothing should be underlined and declared as an error, as the environment local variable has been declared in terraform/config/common.tf.

Actual Behavior

Every reference to a local variable from terraform/config/common.tf now creates an error in VSCode. We have almost 100 stacks in Terraform/Terraspace right now, and those stacks always use one or more references to local variables from terraform/config/common.tf, meaning all of our stacks are shown in red in VSCode due to this.

This was not a problem prior to v2.28.0 of the extension.

Terraform Configuration

#config/terraform/common.tf
locals {
  environment = "dev"
}

#app/stacks/test/locals.tf
locals {
  test=local.environment
}

Project Structure

.
├── app
│   └── stacks
│       ├── test
│       │   ├── locals.tf
├── config
│   ├── app.rb
│   └── terraform
│       ├── backend.tf
│       ├── common.tf
│       └── provider.tf
└── Terrafile

Gist

No response

Anything Else?

N/A

Workarounds

N/A

References

No response

Help Wanted

Community Note

radeksimko commented 1 year ago

This looks like a situation very similar to one explained in https://github.com/hashicorp/vscode-terraform/issues/1581 where locals aren't available. Correct me if I misunderstood.

Regardless of the exact reasons - whether that's internal or any other tooling such as Terraspace - this is not how locals were designed to be used. This is a use case for variables as I tried to explain in my earlier comment in https://github.com/hashicorp/vscode-terraform/issues/1581#issuecomment-1753028165

The extension (and the language server) will always aim to mimic Terraform CLI's own behaviours as closely as possible and missing local values would be raised as errors there too if you run any terraform command which involves configuration (init, plan, apply, destroy, validate, ...).

All that said, we have previously discussed the possibility of making various validations configurable - I will create an issue to track that feature so we at least formalise the idea and link here for more context.

The best workaround I can offer you right now is to use this option which turns off all validations, except for HCL:

"terraform.validation.enableEnhancedValidation": false,

You can read more about the difference between enhanced validation and HCL at https://github.com/hashicorp/terraform-ls/blob/main/docs/validation.md

On a semi-related note, we have recently announced stacks among other features, which are currently available in private beta. You can also watch the keynote (the feature is covered from 31:20 mark).

radeksimko commented 1 year ago

I have yet to create the issue for configurable validations but for now I'm going to close this issue as I believe it describes the same problem as https://github.com/hashicorp/vscode-terraform/issues/1581

github-actions[bot] commented 11 months ago

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.