Consider Documentation for Provider Code with Split Go Packaging

[bflad]

Module version

v1.3.3

Use-cases

Newer Go or Terraform Provider developers that are attempting to scale their provider codebases for multiple "service" or "category" Go packages may not know how to structure their code appropriately. In general, this means that acceptance testing must use the _test Go package convention and there are some other potentially helpful coding patterns, such as creating an interface to retrieve all resources for a given service/category so the service/category package is more self-contained.

Proposal

One upfront option, but unsure whether it is more or less confusing for newer developers, might be updating the existing scaffolding repository and tutorials to use the _test package out of the box. This would alleviate the potentially confusing new requirement when splitting Go packages as it should already be handled or at least more visible for those unfamiliar with the Go testing feature.

A more in-depth, but likely more confusing for newer developers, approach might be updating the existing scaffolding repository and tutorials to use split packaging out of the box. Most providers, at least initially, do not need to be introduced to cross-package imports in Go when everything is easily supported within the same "provider" package.

A more in-depth, but less discoverable, approach might be to introduce a new framework provider into terraform-provider-corner that provides an example of split Go packaging with some of the potential helpers.

A more in-depth and more discoverable, but harder to maintain, approach might be to introduce a new collection in HashiCorp Learn that takes the end of the existing collection and walks through the steps to breaking it into larger code

References

This has come up in the past, but I cannot prioritize finding the additional references at the moment.

• https://discuss.hashicorp.com/t/multiple-packages-in-provider-causes-import-cycle-during-acceptance-testing/56755