IntelliSense for module sources other than local or Registry

[timdhoffmann]

#668 has been closed but for me, module inputs are not working for custom modules imported from GitHub.
Expected example:
I am getting an IntelliSense tooltip for this

when I hover:

Observed example:
I am not getting intellisense for inputs of a module imported from GitHub, e.g.
I am getting IntelliSense for source but not for azure_subscription_id.
Note: I obfuscated some values with <...>.

module "tnc_elastic_azure_monitoring" {
    source = "git@github.com:<account>/terraform-elastic-module"

    azure_subscription_id = "<some_id>"

Extension output:

(...)
2022/07/15 12:01:33 hover.go:32: Looking for hover data at "main.tf" -> hcl.Pos{Line:13, Column:18, Byte:393}
2022/07/15 12:01:33 hover.go:34: received hover data: (*lang.HoverData)(nil)
2022/07/15 12:01:33 rpc_logger.go:45: Error for "textDocument/hover" (ID 335): [-32098] main.tf (13,18): unknown attribute "azure_subscription_id"
2022/07/15 12:01:33 opts.go:218: Completed 1 requests [1.0859ms elapsed]
[Error - 12:01:33] Request textDocument/hover failed.
  Message: main.tf (13,18): unknown attribute "azure_subscription_id"
  Code: -32098 

Additional info

VS Code

Version: 1.69.1 (user setup)
Commit: b06ae3b2d2dbfe28bca3134cc6be65935cdfea6a
Date: 2022-07-12T08:21:24.514Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: 10.0.139.17-electron.0
OS: Windows_NT x64 10.0.22000

Extension

HashiCorp Terraform
v2.23.0

Platform

Windows 11

Originally posted by @timdhoffmann in #715 (comment)

[radeksimko]

Hi @timdhoffmann
Thanks for trying out the recent enhancements!

You are right that we do not currently provide IntelliSense for uninitialized modules except for local modules and the ones sourced from the Terraform Registry. There's no way we can provide it without sacrificing some potentially significant resource (CPU / memory / network) usage.

To provide more context - In order to provide IntelliSense, we need the metadata, such as input/output names and their data types. We can get this relatively cheaply/easily from local modules we can index on disk, or from the Terraform Registry API.

The only way we can do it for modules from any other source is to actually download the module somewhere, so that we can parse it. Depending on module size and amount of modules, this can be prohibitively expensive in terms of resource usage. This is primarily why we leave the module installation up to the user at this point.

i.e. you can run terraform get or terraform init, which installs any modules from any source into .terraform, where we can pick up all the metadata and use it for IntelliSense.

We could theoretically offer some kind of auto-installation (automatically run terraform get or terraform init), but if/when we do, this would likely be turned off by default as it comes with the risks mentioned. Such feature is not currently on our roadmap.

[matschaffer-roblox]

I'm getting a similar error after terraform init on v2.26.1 of the plugin (terraform-ls 0.31.2)

With just this HCL:

module "eks_blueprints" {
  source          = "github.com/aws-ia/terraform-aws-eks-blueprints?ref=v4.29.0"
  cluster_version = "1.25"
}

2023/05/21 18:31:15 hover.go:35: Looking for hover data at "main.tf" -> hcl.Pos{Line:3, Column:11, Byte:117}
2023/05/21 18:31:15 hover.go:37: received hover data: (*lang.HoverData)(nil)
2023/05/21 18:31:15 rpc_logger.go:48: Error for "textDocument/hover" (ID 28): [-32098] main.tf (3,11): unknown attribute "cluster_version"
2023/05/21 18:31:15 opts.go:203: Completed 1 requests [2.231417ms elapsed]
[Error - 6:31:15 PM] Request textDocument/hover failed.
  Message: main.tf (3,11): unknown attribute "cluster_version"
  Code: -32098 

But I can see the variable in the locally-downloaded copy as expected:

❯ grep -E 'variable.*cluster_version' .terraform/modules/eks_blueprints/*.tf
.terraform/modules/eks_blueprints/variables.tf:variable "cluster_version" {

[radeksimko]

@matschaffer-roblox I have extracted your report into a separate issue to keep this one focused on the feature involving uninitialised modules. What you attempted is expected to work, but I can confirm it currently doesn't. Let's take this to #1440

[matschaffer-roblox]

Great, thanks for opening the new issue!

[nickel-tyler]

still doesn't seem to work even with initialized modules

[Cazmill13]

I'm seeing the same issue with modules stored in Azure DevOps repositories.
Sometimes a reload of vscode temporarily fixes the issue, but it comes back if the external module is changed.
It feels like there's a local cache somewhere that does not get updated properly.