UMNFR1 - Module Naming
ID: UMNFR1 - Category: Naming - Module Naming
Utility Modules MUST follow the below naming conventions (all lower case).
Important
The module’s approved name is captured in the module proposal issue. The related module index page and CSV file remain published lookup references.
Module owners must use the name approved in the module proposal, not construct a new one. If it differs from the index, confirm the correction with the AVM core team.
Correct descriptive fields through the metadata review process. Changing moduleDisplayName does not rename the module or change its repository path.
Bicep Utility Module Naming
- Naming convention:
avm/utl/<hyphenated grouping/category name>/<hyphenated utility module name> - Example:
avm/utl/general/get-environmentoravm/utl/types/avm-common-types - Segments:
utldefines 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:generalortypes<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-finderoravm-utl-naming - Segments:
<provider>is a legacy requirement of the Terraform registry. For AVM Terraform utility modules this MUST be set toazure(for exampleAzure/avm-utl-naming/azure). Older utility modules may still use theazurermorazureadsegments. These segments are names only and do not permit use of the AzureRM provider; TFFR3 still requires every module to be built with AzAPI.utldefines 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.