Because detection of the relevant root module for a file/dir is not a trivial task, #176 introduces new functionality which reports all potential candidates for root modules in the context of a directory being initialized/opened, matches the first one and displays warning when there is more than 1.

Picking the right root module from a list of candidates is something that #176 does not solve yet, because there is a number of different factors which may play role in picking.

Use-cases

For example:

• module-alpha is referenced by tf-root-1 and tf-root-2
• module-alpha requires aws provider ~> 2.0
• tf-root-1 requires aws provider ~> 2.0 and has 2.2.0 installed
• tf-root-2 requires aws provider ~> 2.5 and has 2.5.9 installed
• tf-root-2 is probably more relevant, because any compatible higher version is better?

The downside here is that the schema data may not be accurate for tf-root-1.

Proposal

• we can parse the plugin cache to understand what exact plugin versions are installed
• we can detect parse-able files (*.tf) - something which so far only lives on the client side
• we can parse files straight from disk
  • we would need to understand how to parse provider's version and/or terraform's required_providers - something we should understand anyway long-term, but that is a non-trivial task in itself
  • potentially parse many files/directories at the same time. This could have a negative impact on CPU/memory during the initialization.

Then would provide us more context (plugin version constraints and versions installed) to further sort potential candidates for root modules for a given file/directory being opened.

I assume we could generally flag up mismatching plugin constraints between module consumers? This would require some better understanding of how people use plugin constraints in this context.

References

#32
#176