Is there a way to fix "Module not installed" for local submodules?

I’m using vscode-terraform v2.26.1 with vscode 1.78.2 on a mac osx 13.3 (22E252). But the problem is the same when using terraform validate on command line outside vscode.

Executing terraform validate will work fine for local modules as long as it is executed within the same folder as i execute terraform init
But i call a lot of modules from within modules. They are all local modules using relative paths.

So using terraform validate in a module itself, i get the following for all my sourced local modules:

Module not installed: This module is not yet installed. Run “terraform init” to install all modules required by this configuration.terraform validate

Highlighting und autocomplete works fine with those modules (maybe this is the language servers work?), just validation for the submodules won’t work.

Hi @sebastianreloaded

Re terraform validate integration:
This is one of the unfortunate reasons we treat the validateOnSave as experimental feature and generally try to not leverage too much of the CLI under the hood. In general, the CLI makes a lot of assumptions which are unfortunately very inconvenient in the context of an editor.

Much of the other logic you mention (completion, hover, highlighting, very basic HCL validation, go-to-definition, …) is implemented entirely separately from the Terraform CLI for those reasons.

We intend to address the submodule support as part of Support uninitialised submodules in the Registry · Issue #1035 · hashicorp/terraform-ls · GitHub and we also track wider validation efforts in Provide diagnostics and quick fixes for invalid configuration · Issue #720 · hashicorp/vscode-terraform · GitHub. In both cases this would avoid the limitations of terraform validate since it would not use validate at all but it would be implemented “natively” in the language server, which the extension uses.

I hope that helps.

1 Like

btw. we used to have a quick pick or folder picker which would allow you to run validate in a particular path, instead of assuming the currently open folder. It must have gotten lost in some recent refactoring.

Is that something you’d find helpful?

It means we’d validate the whole “tree” of modules from the root, not just that one submodule, so if there are other problems higher up then these would be presented as well, which may not be convenient.