Introduce "module.callers" custom command

[radeksimko]

Current Version

0.16.1

Background

Currently the VS Code extension uses custom command called rootmodules which has historically been used to answer a question of "Where could a module in question be init-ed validate-d etc. from?", i.e. What is its root module?

terraform-ls/internal/langserver/handlers/command/modules.go

Lines 20 to 29 in c4ea46f

	type modulesCommandResponse struct {
	ResponseVersion int `json:"responseVersion"`
	DoneLoading bool `json:"doneLoading"`
	Modules []moduleInfo `json:"rootModules"`
	}
	type moduleInfo struct {
	URI string `json:"uri"`
	Name string `json:"name"`
	}

Internally to answer that question the server would basically inspect module manifests of all initialized modules it found in the hierarchy of the whole workspace.

To maintain compatibility, the rootmodules command currently still returns only initialized modules, or more precisely modules for which it was able to obtain schema via terraform providers schema -json successfully.

A module can have just initialized submodules (e.g. via terraform get) and still be a valid candidate despite our inability to obtain schema (e.g. where plugins were not downloaded or state backend requires auth). Therefore we can be missing some useful suggestions.

Use-cases

Provide clients with a list of paths to module callers, which they can use as a hint in the UI for where to run commands, such as init, validate etc.

Proposal

New Command: module-callers

Introduce new command module-callers accepting a single folder URI, e.g. file:///path/to/module with the following response structure:

type moduleCallersResponse struct {
	FormatVersion int          `json:"v"`
	Callers         []moduleCaller `json:"callers"`
}

type moduleCaller struct {
	URI  string `json:"uri"`
	Name string `json:"name"`
}

Deprecation of rootmodules

It is also proposed to deprecate the existing rootmodules command in favour of module-callers, although I'm not sure what the best way of deprecating it is. Ideally clients (including the VS Code extension) should ask the server whether it supports certain commands before attempting to execute them, but I'm unsure whether this LSP convention is being followed.

Given that this command was historically used to "just" improve the UI, I'm thinking that returning error on execution should only mean that users are forced to type out module paths more often, but it shouldn't block anyone.

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