Export functions for processing module files

[adam-26]

Hi,

Currently it not possible to easily inspect a modules configuration if you need to customise file inspection. The changes in this PR only export existing functionality. If you want to perform any custom inspection of module files currently you'd need to re-write, copy/paste or fork the repo, these changes allow you to quickly start processing a module as you need.

I'm not sure if it's within the intended scope of this project, but I think it would be useful. Some of the existing PRs and issues could be solved by using these functions to augment the output of the LoadModule*() functions.

Exports the following functions to allow callers to inspect the files of a terraform module:

1. LoadModuleFiles: Invokes a callback function for each file in a module
2. LoadModuleFilesFromFileSystem: As above, with additional FS arg
3. IsOverrideFile: Uses filename to determines if a file is an override file

Let me know if you have questions. Feel free to rename the functions.

Thanks, Adam.

[hashicorp-cla]

)
All committers have signed the CLA.

[adam-26]

And here's a quick example usage:

diags := tfconfig.LoadModuleFiles(".", func(file *hcl.File, filename string) hcl.Diagnostics {
    // Process file blocks/attributes here
    isOverride := tfconfig.IsOverrideFile(filename)
})

[apparentlymart]

Hi @adam-26! Thanks for working on this.

What you've done here does seem to be a layer below the intended level of abstraction of this module, exposing the details of how a module is built from files rather than just the effective configuration resulting from those files.

Part of the requirements for this library API is that it be able to support both historical versions of the Terraform language back to Terraform v0.10 and as much as possible to support future versions of the language that aren't designed yet. The level of abstraction is therefore chosen to expose things at the level of concepts Terraform itself relies on, rather than the specific details of how those are encoded on disk.

Given that, my first reaction is that what you've added here is out of scope and makes me concerned that it may constrain future evolution of this library to support future versions of the language that might have a different on-disk representation. I would be interested to hear more about what you intend to do with the information this would expose, but I want to be up front that the bar for growing the API to include this new level of abstraction is pretty high, given the long-term maintenance requirements we have for this codebase.

Thanks again!

[adam-26]

@apparentlymart, thanks for the quick response. I understand your concerns.

I need to augment the data returned by the LoadModule() function with some other data from the configuration files. Currently this requires using a lot of code thats already available in this project. I'll just use my fork :)

Thanks again, Adam.