UMNFR1 - Module Naming

ID: UMNFR1 - Category: Naming - Module Naming

Utility Modules MUST follow the below naming conventions (all lower case).

Important

As part of the module proposal process, the module’s approved name is captured both in the module proposal issue AND the related module index page (backed by the corresponding CSV file).

Therefore, module owners don’t need to construct the module’s name themselves, instead they need use the name prescribed in the module proposal issue or in the related CSV file, at the time of approval.

Bicep Utility Module Naming

  • Naming convention: avm/utl/<hyphenated grouping/category name>/<hyphenated utility module name>
  • Example: avm/utl/general/get-environment or avm/utl/types/avm-common-types
  • Segments:
    • utl defines this as a utility module
    • <hyphenated grouping/category name> is a hierarchical grouping of utility modules by category, with each word separated by dashes, such as: general or types
    • <hyphenated utility module name> is a term describing the module’s function, with each word separated by dashes, e.g., get-environment = to get environmental details; avm-common-types = to use common types.

Terraform Utility Module Naming

  • Naming convention:
    • avm-utl-<utility module name> (Module name for registry)
    • terraform-<provider>-avm-utl-<utility module name> (GitHub repository name to meet registry naming requirements)
  • Example: avm-utl-sku-finder or avm-utl-naming
  • Segments:
    • <provider> is the logical abstraction of various APIs used by Terraform. In most cases, this is going to be azurerm or azuread for resource modules.
    • utl defines this as a utility module
    • <utility module name> is a term describing the module’s function, e.g., sku-finder = to find available SKUs; naming = to handle naming conventions.