Display module hierarchy in the UI

[radeksimko]

Use Cases

Many users use modules to abstract away conventions and common logic. They would benefit from knowing what modules does their module depend on and whether these modules have any other (transitive) module dependencies, all without having to browse through all the config files.

Expected User Experience

The expectation is that we'd use Tree View API, which would look approximately like this:

we may also consider adding the view directly under the Explorer menu, similar to this example from VS Code docs:

User would be able to see:

• hierarchy of modules called from the module(s) being edited
• where is that module being sourced (locally, Terraform Registry, GitHub, ...)
• what version of that module is required/installed
• right click to update outdated module, where applicable (Terraform Registry)
• right click to go to the docs of the module, where applicable (Terraform Registry)

We may also consider implementing this as a WebView https://code.visualstudio.com/api/extension-guides/webview

Proposal

• decide UI details - i.e. what exact metadata and how we display
• expose the relevant module data from LS via custom command
• implement the client-side while leveraging the data from LS obtained via custom command

[radeksimko]

To summarize what we discussed w/ @jpogran today for posterity:

A question came up about what modules do we want to display in the UI. The initial idea was we would display just module calls of the module being edited, but it seems that the convention for similar tree views is to be relatively independent of the editor views and encompass the whole hierarchy of the top directory that is open in the workspace (whether or not any file from anywhere within the hierarchy is open).

This opinion is supported mainly by Git Lens: https://gitlens.amod.io/#features where the extension would view all repositories within the hierarchy, as opposed to just the repository being edited.

The latest version of the LS currently doesn't index all modules within the hierarchy, so if we are to pursue this idea of "high-level view" then we would need to change the implementation and do full indexing, so that we can actually obtain all modules and display all the data and avoid user-end confusion due to missing modules/data there.

This may seem like a relatively simple change, but we still do need the module to have its own modules installed so that we can access the module manifest which contains metadata about all the modules in a readable format and more importantly would discover transitive dependencies. For example:

moduleA/main.tf

module "module-b" {
  source = "github.com/hashicorp/module-b"
}

github.com/hashicorp/module-b

module "module-c" {
  source = "github.com/hashicorp/module-c"
}

Assuming we are editing moduleA above we wouldn't know that the module-b also brings in module-c until we actually run terraform get or terraform init within moduleA and install module-b.

While tracking uninitialized modules is a reasonable ask for some other reasons (such as go-to-definition for local submodules), it's not what we do currently in LS and would be a non-trivial amount of work to get it implemented at this moment.

[radeksimko]

We can collect more feedback on this, but I would argue that maybe this is the difference between Explorer pane and a dedicated view with custom icon where a dedicated view is expected to be more high-level on the whole workspace, but the Explorer view can provide data relevant just to the directory in focus?

At least it seems that's how the Outline pane behaves:

With that in mind I feel that the initial idea of displaying just modules relevant to the module in focus is not wrong if implemented in this way. However it does mean we should account for a few edge cases in the UI and display a corresponding (helpful) message:

• user has no module in focus
• user is focused on a module which wasn't initialized (i.e. we don't have access to the module manifest)

[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.