Vscode-terraform: Support multiple Terraform folders in a single workspace

[paultyng]

I have a "workspace" in VSCode that has multiple folders (in this case, one was the LS, and one was a TF config, but also when working on a provider I have the provider Go code and a TF config folder open).

If the TF folder is not the first one listed, the terraform init / working dir provider to the LS is incorrect. I'm not sure if this is an LS bug, a VS Code extension bug, or both?

[paultyng]

For now I just move my TF folder to the top of the list and it all works ok, so I'm guessing there are just some assumptions somewhere that are incorrect about what folders to pass/use.

[matt-forster]

This would also be the case for a single-folder workspace that has multiple terraform projects inside it;

tf-monorepo/
-- shared_modules/
-- env_one/
-- env_two/
-- env_three/

[paultyng]

@forstermatth in that case, you init in each one?

[matt-forster]

Yep; we have a couple scripts within the repo's package.json right now for commit hooks, which give a good example.

"scripts": {
    ...
    "terraform:validate": "cd ${WORKING_DIR} && terraform init -input=false -backend=false > /dev/null && terraform validate",
    "validate:production": "WORKING_DIR=./terraform/production npm run terraform:validate && echo ✅ validate:production success",
    "validate:staging": "WORKING_DIR=./terraform/staging npm run terraform:validate && echo ✅ validate:staging success",
    "validate:west": "WORKING_DIR=./terraform/west npm run terraform:validate && echo ✅ validate:west success",
    "validate:vault": "WORKING_DIR=./terraform/vault-config npm run terraform:validate && echo ✅ validate:vault success"
}

[smiller171]

@paultyng yes. This is an _extremely_ common pattern with Terraform. All of my repos that aren't just modules to be consumed elsewhere have multiple projects in a single repo. We use Atlantis to manage it, or cd into the project we're working with at that time.

The language server started by @juliosueiras https://github.com/juliosueiras/terraform-lsp didn't have these problems at all

[paultyng]

@smiller171 you can change the LS binary you are using to use Julio's (we are also working with him on ours). The terraform-ls project has different limitations than terraform-lsp (you can review them in the README for the ls), as the ways Julio is interacting with Terraform are version specific and not the supported interface for interacting with it.

[smiller171]

I get that, but the limitations for terraform-ls are much more severe right now unfortunately. Not being able to work with multi-project repos is a huge thing, and I can't get it working even in a single project repo.

[blairham]

I think maybe an option to select which language server to use for this release until those issues are resovled?

[paultyng]

I wrote up #335 to see if we can add something in the configs or extension prior to release to allow people to more easily choose/install, especially now while the feature sets diverge more.

[zemanlx]

It may be useful to have it as a VSCode workspace settings where I point where it should expect terraform roots.

These are my usual repo structures with terraform:

environments/
  lab/
    .terraform/
  live/
    .terraform/
modules/
README.md

or when it is project based

bin/
src/
test/
terraform/
  .terraform/
README.md
...

To be honest I do not have any repo where .terraform lives in the repo root. So if I would be able to set where the extension should expect .terraform to live it would be awesome! Ideally, for more than one terraform environment.

[nodakai]

Was it not an option to release a beta version as an extension file (VSIX? I'm not an expert here) which courageous volunteers can manually install before pushing this huge deal-breaker regression to the whole world? _Cf._ https://github.com/microsoft/vscode/issues/15756

[smiller171]

@nodakai They did, and several of us told them _explicitely_ that this shouldn't be released as-is

[CallMeLaNN]

I think recent update is a breaking change and it was quite rush to switch while the language server is just being developed since Feb.

---

_extremely_ common pattern

Agreed and I got that from experience restructuring project(s) over time.

It will reduce time to refresh a lot of states, different providers version and focus on application specific resources. Just use terraform_remote_state to another project for dependency and getting outputs.

Things like VPC, subnets, route tables, some IAM policies and CI/CD is a lot and less frequent to change compare to application infra. Some simple application using lambda + API gateway while other applications using Kubernetes/Helm.

So it is incomplete without this support with or without workspace. Anyway it seems promising after seeing this https://github.com/hashicorp/terraform-ls/pull/167

[bruceharrison1984]

Same issue. We use a mono-repo structure similar to:

• root
  |- app
  |- database
  |- terraform

This extension is totally broken for us right now

[trodemaster]

As a workaround you can add a terraform project as the first listed folder in your vscode workspace. That should get you working until the fix is released.

[paultyng]

Linking this to another relevant tracking issue on the LS: https://github.com/hashicorp/terraform-ls/issues/32

[radeksimko]

v0.4.0 (of the language server) was published earlier today. This update should pop up automatically on the next VSCode launch, unless you configured it to point to a custom build.

v0.4.0 initially supports the following hierarchies https://github.com/hashicorp/terraform-ls/tree/master/internal/terraform/rootmodule/testdata with the caveats that wrong root module may be picked up when there is multiple candidates (see https://github.com/hashicorp/terraform-ls/issues/179 and https://github.com/hashicorp/terraform-ls/issues/180 ) and these root modules have to be initd. There is no way of setting custom root modules yet - see https://github.com/hashicorp/vscode-terraform/issues/396

Keep in mind there is also https://github.com/hashicorp/terraform-ls/issues/128 which you may still run into - workaround is mentioned in the thread.

[hashibot[bot]]

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 context necessary to investigate further.