Is it possible to use a single lockfile for multiple directories?

I’m working on a project that is currently managed as about a bazillion folders, each with their own purpose: Our Datawarehouse is in one folder, production databases in another, ecs in a third, etc. We have to terraform init each one separately. Terragrunt would be nice, but is not in use.
Most of our configuration was written in 0.13.4 through 0.13.7, but we’re working on an upgrade. This means that every folder has to be upgraded to 0.14.x, tested, validated, upgraded to 1.1, tested, validated, and pushed to Version Control. This is a lot of work, but it’s expected.

A side effect of this is that every folder is getting its own .terraform.lock.hcl file, and they’re pretty much all the same.

Is it possible, from command-line or in config files, to tell TF: “Always put the lockfile in this specific directory, and always look in this directory for a lockfile”?
If it’s possible, is it a good idea?

For reference, by the end of the upgrade we will have about 200 lockfiles, and 95%+ will be exactly the same.

With regards to the “is it a good idea” part of the question: The lock file is one method of listing the exact versions of providers to use, with the idea that you should be specific, instead of just getting the “latest” version which changes over time and may cause issues (either breaking a deployment due to large changes or subtle differences due to smaller fixes/features).

Splitting an overall set of resources into multiple root modules (either structured as a few repos with different directories or a repo per root module) is very common and usually a good idea. Some things are very difficult to do in a single terraform run (e.g. deploying something inside a Kubernetes cluster that has just been created), other times you have very different release cadencies, different risk profiles, different ownerships, or just want things to be quicker/allow for parallel deployments.

For all those cases having the ability to choose the versions of providers separately can be very important. For example if a major new version of the AWS provider appears that requires extensive code changes with your multiple root module setup you can do those changes a bit at a time - but that only works if you can set the version to be different between the various modules. If you have a single central list you would have to upgrade all the code at the same time (or have the even worse situation that some modules can’t be run for a while becuase they are yet to be updated).

So my opinion would be that having the ability to set the provider versions separately is a good idea.

Hi addition to @stuart-c’s advice (which I broadly agree with), I want to add a technical note that the lock file also serves as Terraform’s manifest of what it should expect to find in the .terraform/providers directory in order to consider a working directory to have been initialized correctly, and also to determine whether a saved plan is being applied with the same set of providers that generated the plan.

If you try to share lock files across multiple configurations which don’t have exactly identical provider requirements then I expect you’d run into problems whereby working in one directory could make another working directory invalid, because its local provider cache would not exactly agree with what’s recorded in the lock file. In that case, running Terraform in those other directories would cause Terraform to return an error saying that the local provider cache is inconsistent, and that you need to run terraform init to fix it, which could then in turn break the lock file for some other directory too.